[22938] in bugtraq
Re: gm4 format strings on OSX
daemon@ATHENA.MIT.EDU (Peter Pentchev)
Mon Oct 22 11:07:43 2001
Date: Mon, 22 Oct 2001 04:32:23 +0300
From: Peter Pentchev <roam@ringlet.net>
To: dotslash@snosoft.com
Cc: bugtraq@securityfocus.com, bug-gnu-utils@prep.ai.mit.edu
Message-ID: <20011022043223.A1115@straylight.oblivion.bg>
Mail-Followup-To: dotslash@snosoft.com, bugtraq@securityfocus.com,
bug-gnu-utils@prep.ai.mit.edu
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="IS0zKkzwUGydFO0o"
Content-Disposition: inline
In-Reply-To: <CEED4600-C58F-11D5-9986-00039305969A@snosoft.com>; from dotslash@snosoft.com on Sat, Oct 20, 2001 at 12:22:31PM -0700
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Sat, Oct 20, 2001 at 12:22:31PM -0700, dotslash@snosoft.com 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.
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="m4.c.patch"
--- src/m4.c Mon Oct 22 04:25:47 2001
+++ src/m4.c Mon Oct 22 04:26:03 2001
@@ -369,7 +369,7 @@
case 'o':
if (!debug_set_output (optarg))
- error (0, errno, optarg);
+ error (0, errno, "%s", optarg);
break;
case 's':
@@ -466,7 +466,7 @@
fp = path_search (argv[optind]);
if (fp == NULL)
{
- error (0, errno, argv[optind]);
+ error (0, errno, "%s", argv[optind]);
continue;
}
else
--IS0zKkzwUGydFO0o--
