OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 4th quarter (Oct-Dec) 1995: Re: a point is being missed

Re: a point is being missed

Douglas Siebert (dsieberticaen.uiowa.edu)
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
dsieberticaen.uiowa.edu