On Sat, Oct 20, 2001 at 12:22:31PM -0700, dotslashat_private 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.
This archive was generated by hypermail 2b30 : Mon Oct 22 2001 - 08:17:11 PDT