m4-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU M4 1.4.8 released


From: Eric Blake
Subject: Re: GNU M4 1.4.8 released
Date: Tue, 28 Nov 2006 06:18:45 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Santiago Vila on 11/27/2006 4:48 PM:
> On Mon, 20 Nov 2006, Eric Blake wrote:
> 
>> The changes in this version trigger spurious testsuite failures in the
>> Autoconf 2.60 testsuite; if you use GNU Autoconf, it is suggested that
>> you upgrade to Autoconf 2.61 after upgrading to M4 1.4.8.
> 
> I'm curious: Will this release likely break packages using autoconf,
> or just autoconf itself?

Neither.  The difference between M4 1.4.7 and 1.4.8 is in the error
message output (ie, line number reporting now tracks the line that a macro
invocation starts on, rather than ends on).  But a well-formed
configure.ac and friends should not cause errors, therefore there is no
line numbering information to be changed.  The resulting configure should
be identical, unless you use the __line__ macro, regardless of which
combination of autoconf 2.60/2.61 or M4 1.4.7/1.4.8 you use, and the minor
difference in the __line__ macro should be considered an improvement.

The disclaimer I gave is more a notice to users that there are known
testsuite bugs in autoconf 2.60 (ie. it is not tolerant to the new error
output style of M4 1.4.8), and that those test suite failures have since
been fixed in autoconf 2.61 to be M4 version agnostic.

> 
> I ask because I'm not sure if this release is suitable to be uploaded
> for Debian unstable.

On the other hand, I would argue that keeping any version of M4 1.4.7 or
earlier is a security risk, now that I have documented the known failure
that you can use the divert macro to cause an allocation wraparound on a
32-bit platform.  While I have not proven that there is an attack vector
that will cause anything other than a core dump, I suspect that it is
possible to use a sequence of diverts to trick M4 1.4.7 into trying to
allocate 4 gig of memory (which will succeed in allocating a minimal array
instead), then dereference memory in the stack by using a diversion number
that M4 thinks belongs to the array, in such a manner that arbitrary code
can be executed.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFbDc184KuGfSFAYARAgQPAJ0ScM3qUu1yB2B9yA6cnLKoWWYU2wCdHCLh
lZqyfh+Fzt6ZTFWkhQulAfA=
=cRce
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]