Re: gm4 format strings on OSX

[Peter Pentchev]

On Sat, Oct 20, 2001 at 12:22:31PM -0700, address@hidden wrote:
> This in itself is not an issue due to the lack of a suid bit... however 
> if I remember correctly there were a few linux suid root binaries that 
> were reliant
> upon m4 in some way or another thus making them vulnerable to a local 
> root expoit. This is on osx 10.1.
> 
> [OSXBOX:~] elguapo% ls -al `which m4`
> -r-xr-xr-x  1 root  wheel  26696 Sep  2 20:59 /usr/bin/m4
> [OSXBOX:~] elguapo% ls -al `which gm4`
> -rwxr-xr-x  1 root  wheel  97464 Sep  2 20:53 /usr/bin/gm4
> [OSXBOX:~] elguapo% m4 %p
> m4: %p: No such file or directory
> [OSXBOX:~] elguapo% gm4 %p
> gm4: 0x4f4d453d: No such file or directory
> [OSXBOX:~] elguapo% gm4 %s
> gm4: Memory bounds violation detected (SIGSEGV).  Either a stack overflow
> occurred, or there is a bug in gm4.  Check for possible infinite 
> recursion.
> Segmentation fault

[CC'd to bug-gnu-utils, hopefully this is the right address; if it is
 not (GNU seems to have moved away from prep.ai), then please somebody
 notify the current m4 maintainers]

Confirmed with GNU m4 1.4 on FreeBSD 4.4-STABLE as of Oct 21.

The attached patch fixes the reported segfault and one other unsafe
use of the m4 internal function error().  I have not looked at other
functions within m4 that might use printf(3) and friends unsafely,
so there might be other bugs lurking about.

G'luck,
Peter

-- 
If this sentence were in Chinese, it would say something else.

m4.c.patch
Description: Text document