Bugtraq mailing list archives
Re: a point is being missed
From: dsiebert () icaen uiowa edu (Douglas Siebert)
Date: Fri, 3 Nov 1995 18:39:51 -0600
Why in all this telnetd flap has nobody mentioned that /bin/login should be relinked STATICALLY? That at least defers the LD_* class of problem until after login has done the setuid and exec, but still leaves things like IFS passed to scripts. Still, my own rule of thumb is that any binary that talks to the net, handles inbound connections, handles authentication, etc ... should not be depending on shared libs. It's well worth the miniscule disk space hit. Vendors, LISSEN UP.
I disagree quite strongly. Assuming your implementation of shared libraries is sane, like HP's, you should not even have to worry about this class of attacks. HP requires a compile-time option to the linker to ALLOW changing the library search path via an environment variable. You can also change this attribute on an existing binary using the 'chatr' (change attribute) command. So you get all the flexibility the others offer, but without the headache of worrying about your system binaries, unless you are going around indiscriminately using chatr on them (or a cracker does after he gets into your system, but you should reinstall in that case anyway) The REAL value of shared libs IMHO is the fact that you can patch a bug or add a feature in the shared library, and instantly upgrade everything linked with it. Let's say a bug was discovered in some standard libc function that would allow you to perform actions as the uid of the process using that libc function. Oh, for the sake of argument, we'll say it was syslog() :-) If you can get telnetd, or any of a very large class of executables that run as root to perform that call for you in the way you want, you're in a lot of trouble. If you can just patch the libc and maybe a handful of statically linked executables (how many things would run as root at the behest of a user are there that are statically linked on a normal system -- i.e., in /sbin?) you fix the hole. Much easier than patching 50 different executables -- how long would it take for the vendor to recompile and release patches for that many things?! I'd hate to think about fixing the syslog hole on such a system, it might as well be a system without shared libraries at all! You essentially need to release a new rev of the OS as a carrot to get people to upgrade (not that that is any guarantee people do, but it is more likely than getting them to install dozens of patches) -- Doug Siebert dsiebert () icaen uiowa edu
Current thread:
- Re: SunOS syslog() fix, finally..., (continued)
- Re: SunOS syslog() fix, finally... Pug (Nov 10)
- Turning dynamic into static? Lawrence R. Rogers (Nov 09)
- Re: Telnet attack on SGI Adam Shostack (Nov 02)
- Does the shared lib bug work on any suid program ? Bernd Lehle (Nov 03)
- Re: Does the shared lib bug work on any suid program ? Fred Blonder (Nov 03)
- Re: Does the shared lib bug work on any suid program ? John Capo (Nov 03)
- Re: Does the shared lib bug work on any suid program ? Justin Mason (Nov 06)
- a point is being missed *Hobbit* (Nov 03)
- Re: a point is being missed Scott Barman (Nov 03)
- Re: a point is being missed John Stewart (Nov 03)
- Re: a point is being missed Douglas Siebert (Nov 03)
- Re: a point is being missed Richard Todd (Nov 04)
- Re: a point is being missed Casper Dik (Nov 04)
- Re: Telnet attack on SGI Edwin Kremer (Nov 09)
- Re: Telnet attack on SGI Edwin Kremer (Nov 10)
- Re: Telnet attack on SGI Sam Hartman (Nov 01)
- Re: Telnet attack on SGI Casper Dik (Nov 06)
- Re: Telnet attack on SGI Adrian (Nov 03)
- Re: Telnet attack on SGI Sam Hartman (Nov 03)
- Re: Telnet attack on SGI Michael/Miguel Sanchez (Nov 09)
- Re: Telnet attack on SGI Michael/Miguel Sanchez (Nov 10)