[2340] in bugtraq
Re: Telnet attack on SGI
daemon@ATHENA.MIT.EDU (Robert A. Pickering Jr.)
Thu Nov 2 20:33:09 1995
Date: Wed, 1 Nov 1995 16:10:56 -0500
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: "Robert A. Pickering Jr." <pickerra@MUOHIO.EDU>
X-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: <199511011759.AA128338791@l-ecn036.icaen.uiowa.edu>
Hmmm,
This doesn't seem to work on my Indy running Irix 5.3:
neelix 1% telnet
telnet> environ define _RLD_ROOT /tmp
telnet> environ export _RLD_ROOT
telnet> o localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
IRIX System V.4 (neelix)
Connection closed by foreign host.
neelix 2%
Did I attempt the exploit wrong?
-Rob
On Wed, 1 Nov 1995, Douglas Siebert wrote:
> I've been playing with the telnet attack on the SGI, trying to figure out a
> good way around it since SGI apparently doesn't have a patch ready yet. I
> have figured an easy way to show how the bug operates, but haven't figured an
> easy way to stop it.
>
> # telnet
> telnet> environ define _RLD_ROOT /tmp
> telnet> environ export _RLD_ROOT
> telnet> o localhost
> Trying 127.0.0.1...
> Connected to localhost.xxx.xxx.xxx
> Escape character is '^]'.
>
>
> IRIX System V.4 (xxx)
>
> 7480:login: rld: Fatal Error: cannot map soname 'libgen.so' using any of the
> filenames /tmp/usr/lib/libgen.so:/tmp/lib/libgen.so:/tmp/lib/cmplrs/cc/libgen
> .so:/tmp/usr/lib/cmplrs/cc/libgen.so:/tmp/usr/lib/libgen.so.1:/tmp/lib/libgen
> .so.1:/tmp/lib/cmplrs/cc/libgen.so.1:/tmp/usr/lib/cmplrs/cc/libgen.so.1: -- e
> ither the file does not exist or the file is not mappable (with reason indica
> ted in previous msg)
> Connection closed by foreign host.
> #
>
> _RLD_ROOT isn't the only variable that the runtime linker will understand, I
> just picked this one as a good example. If you do a 'tog opt' in telnet before
> you open the connection to localhost you can watch the option negotiation and
> see the _RLD_ROOT variable being passed.
>
> There are two ways I know of to protect against this attack until SGI has a
> patch ready. One would be to write a wrapper that removes "dangerous"
> environment variables. Obviously, figuring out which ones are dangerous is
> the trick! Certainly anything that starts LD_ or _RLD should be removed. But
> there may always be others you don't know about. You'd take your wrapper and
> call it /usr/lib/iaf/scheme and rename the real /usr/lib/iaf/scheme to
> something like /usr/lib/iaf/scheme.real and have your wrapper call it (see
> below) You'd have to compile it non_shared, so it doesn't get hijacked by
> the bad environment variables itself. The other way I found is guaranteed to
> work, but breaks login slightly. If you create a simple wrapper program as
> follows:
>
> main(argc, argv)
> int argc;
> char **argv;
> {
> setuid(1);
> execv("/usr/lib/iaf/scheme.real", argv);
> }
>
> And compile it with the -non_shared option, call it /usr/lib/iaf/scheme and
> rename the old /usr/lib/iaf/scheme to /usr/lib/iaf/scheme.real, then you
> effectively have telnetd calling your wrapper, which sets its uid to 1, then
> calls the real login. I've only tested this on Irix 5.3, and most of my
> experience is with HPs, so I don't know if this works for all releases. But
> I know that on my 5.3 machine, telnetd calls /usr/lib/iaf/scheme directly,
> instead of /bin/login (which is a link to /usr/lib/iaf/scheme) Since the real
> login is not started as root, you see some odd things. I've noticed two
> things in particular: you get an error because quota is being run as uid 1
> instead of root when you login, and rlogin no longer works with .rhosts. I
> assume that's because login will only accept some options when not run as
> root, for obvious reasons. There may be other problems with it as well. But
> since login is setuid, the uids don't match and the runtime linker won't honor
> any of the "dangerous" variables.
>
>
> I'm curious exactly to see exactly how the various vendors that have this
> vulnerability choose to fix it in the long term. In the short term, patching
> telnetd seems to be the solution. But what if the dynamic linker gets a new
> variable in the future, and the people responsible for that don't let the
> people responsible for telnetd know? A better fix, IMHO, would be some sort
> of way to compile some executables without support for altering paths in this
> way. HP by default does not allow you to modify the searching rules used for
> finding shared libraries. But with a linker option, you can allow the
> environment variable SHLIB_PATH to modify the searching rules. Its a bit less
> flexible than, say, Sun or SGI, but there are no worries about this sort of
> attack ever being possible unless HP compiled system binaries with this
> option, which they would of course be crazy to do.
>
> --
> Doug Siebert
> dsiebert@icaen.uiowa.edu
>
-- Everything below this line is my signature, it is not directed at anyone
Robert A. Pickering Jr. UNIX Software Specialist
Miami Computing and Information Services pickerin@muohio.edu
PGP key ID: 75CAFF7D 1995/05/09
PGP Fingerprint: B1 63 0C 09 D8 2E 5D 69 BB 61 A2 92 22 37 63 C3
"Most people, if they counted how many people swam across the river, would
never think about building bridges." - Ronald Altman
