[466] in linux-security and linux-alert archive
Re: ld.so gaping hole.
daemon@ATHENA.MIT.EDU (SysAdmin - TNET Systems)
Wed Nov 8 17:03:47 1995
Date: Mon, 6 Nov 1995 23:55:19 -0600 (CST)
From: SysAdmin - TNET Systems <root@TNET.portage.net>
To: Joshua Cowan <jcowan@jcowan.reslife.okstate.edu>
cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199511070352.VAA29247@jcowan.reslife.okstate.edu>
On Mon, 6 Nov 1995, Joshua Cowan wrote:
> CG> the telnetd hole was minor, because anyone could use the
I meant simply, the alledged 'telnet bug' was only a symtom of a much
larger problem, which is the hole(s) in ld.so.
> CG> LD_LIBRARY_PATH and LD_PRELOAD to get root with just about
> CG> anything. patching login, telnetd, ect ect is not going to
> CG> fix this problem.
>
> Uh, no. And yes, patching `telnetd' (or statically linking `login',
> or using a wrapper) will fix this problem.
>
I meant it will not fix the 'ld.so' hole. I don't think you understand
how big this hole is or how much of a problem it is.
A wrapper on 'login' or modifications to 'telnetd' will fix the telnet
hole. Staticly linking login, as well as setting the SUID/GUID bits
did not correct the problem for me. I am using a.out 1.3.37,
ld.so 1.5.3. None of the 'quick fixes' other then modifying telnetd worked
for me. I am baffled on why static linking did not work. However,
a few have reported the same results with static linking. :/
> CG> LD_PRELOAD, LD_LIBRARY_PATH are really not needed. If you
>
> Although I agree that many utilities are at least somewhat subject to
> creeping featurism, I would have to disagree with this one. If you
> want to test a dynamically-linked binary without installing the
> dynamic-lib (and you don't want to use `-rpath'), then this becomes
> very useful.
>
*
> CG> are going to use them, rename them, hash the names up in the
> CG> ld.so binary (evade strings), or use some sort of protocol
> CG> for specifying them.
>
> You may as well disable them altogether if you are going to do this.
> Besides, this is not virus code we are dealing with and we don't need
> really to ``hide'' the variables values from anyone.
>
The point is: any user can run 'strings' on 'ld.so' and check for the
names of the environment variables. Masking these names from 'strings'
would be an appropriate answer to this problem. Remember, this is about
security, and the balance of security between ease of use.
> CG> For example, modify the ld.so.c file to search for a special
> CG> char, of your choosing, in the environment variables. If
> CG> not present, ignore the variables.
>
> Again, this is (IMHO) pointless --- you may as well remove the
> features altogether. It is very conceivable that other users on the
> system may have need for these features, in which case doing this
> would only make your job more difficult.
>
* If you have users wanting to redirect the loading of a library, then the
users should very well be informed of the new names of the environment
variables. I cannot see how this would be a problem. If you have
developers on your system, and trust them to use different libraries,
then they are obviously trusted enough to obtain this information
Another option, and a much better one at that, would be to edit ld.so.c
to only allow the use of these environment vars if the user belongs to a
specific group, eg: developers Using this method, you could keep the
old names of the environment vars, and allow trusted users access to that
particular group.
> CG> So not only to you get to save disk space (although nominal)
> CG> over adding patches, or wrappers... you get an even much
> CG> more securer system.
>
> Well, I'd have to agree that it _is_ more secure, although I don't
> know how much. I personally think that the features are worth what
> little trouble they cause.
>
consider a user having used another program, other then 'login', to gain
access to this hole. This is what I am trying to avoid. Any SUID binary
on your system can be exploited this way.
Chad Giffin
TNET Information Systems, Canada
(204) 857-5754
cgiffin@portage.net
---
