[4045] in bugtraq
Re: Linux NLSPATH buffer overflow
daemon@ATHENA.MIT.EDU (Alan Cox)
Fri Feb 14 19:13:54 1997
Date: Fri, 14 Feb 1997 20:51:02 +0000
Reply-To: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
From: Alan Cox <alan@LXORGUK.UKUU.ORG.UK>
X-To: solar@IDEAL.RU
To: BUGTRAQ@netspace.org
In-Reply-To: <199702140408.XAA07346@netspace.org> from "solar@IDEAL.RU" at Feb
13, 97 11:08:13 pm
> I'm sorry if the information I'm going to tell about was already known, but
> I hope it wasn't...
Its known, its fixed in current setups
> It might be possible to exploit this hole remotely, if using a patched telnet
> client which would allow exporting large environment variable values. The
> overflow would happen at /bin/login startup then (somewhat like the famous
> LD_PRELOAD exploit, but an overflow). I'm not sure of that though, there might
> be some restrictions on environment variables in telnetd.
Netkit 0.08/9 telnetd do not pass any environment variables,
> As for the fix, well, this is a hard one -- would require re-compiling libc,
> and statically linked binaries. To protect yourself against remote attacks,
> you could for example change the variable name to something different, with
> a hex editor (like /usr/bin/bpe), in /lib/libc.so.5, and ensure the exploit
> stopped working. Of course, this is only a temporary fix.
libc5.4 is immune, RedHat has been shipping the fixed libc5.3.12 for a long
time, and all the vendors I had security contacts for where told ages ago.
If they haven't fixed it then Im disappointed with them, they dont have
an excuse. That libc5.3.12 unpatched also has other fun bugs with buffer
overruns in libc some in the BSD stuff akin to the BSD bugs in rcmd() etc.
Alan
