[471] in linux-security and linux-alert archive
Re: ld.so gaping hole.
daemon@ATHENA.MIT.EDU (Joshua Cowan)
Wed Nov 8 17:09:27 1995
Date: Tue, 7 Nov 1995 02:24:24 -0600
From: Joshua Cowan <jcowan@jcowan.reslife.okstate.edu>
To: SysAdmin - TNET Systems <root@TNET.portage.net>
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.LNX.3.91.951106225831.5382A-100000@TNET.portage.net>
>>>>> "CG" == SysAdmin <- TNET Systems <root@TNET.portage.net>> writes:
CG> I meant it will not fix the 'ld.so' hole. I don't think you
CG> understand how big this hole is or how much of a problem it
CG> is.
This is correct, I don't understand how big this ``hole'' is or even
where it is. ;-) I don't think you understand this feature's
implementation, but that doesn't mean you don't. :-)
CG> other then modifying telnetd worked for me. I am baffled on
CG> why static linking did not work. However, a few have reported
CG> the same results with static linking. :/
Hmm... If this is accurate, then this _is_ a problem (again, IMHO)
--- albeit not the ``hole'' that you are reporting. I don't see how
the dynamic linker can be coerced into replacing symbols in the
executable image with external ones, tho --- it's job is to resolve
the undefined symbols only, AFIAK.
CG> The point is: any user can run 'strings' on 'ld.so' and check
CG> for the names of the environment variables. Masking these
CG> names from 'strings' would be an appropriate answer to this
CG> problem. Remember, this is about security, and the balance of
CG> security between ease of use.
I don't think this is a problem under the current implementation: it
would be a pain for each site to generate a ``password'' so it could
protect a feature of `ld.so' from ``normal'' users (I say ``password''
because that is essentially what this is doing). As far as increased
security with the dynamic linker, the HP implementation as described
by Aleph One is the best I've heard thus far (although it would mean
another big change in the system software). I happen to think the
implementation of `ld.so' is _at_least_ adequate, tho.
CG> would be a problem. If you have developers on your system,
CG> and trust them to use different libraries, then they are
CG> obviously trusted enough to obtain this information
CG> if the user belongs to a specific group, eg: developers Using
CG> this method, you could keep the old names of the environment
CG> vars, and allow trusted users access to that particular group.
I imagine this being bothersome, especially when you consider that, if
you use the first suggestion, you will have to implement a
site-dependent method of generating the environment strings (and that
would be a _big_ problem for distribution developers).
As for the second, sites would inevitably end up with uid 0 in the
group of trusted users and encounter the same problem all over again.
CG> 'login', to gain access to this hole. This is what I am
CG> trying to avoid. Any SUID binary on your system can be
CG> exploited this way.
It (the telnetd hole) has nothing to do with the binary being
suid/sgid.
--
Joshua Cowan <jcowan@hermit.reslife.okstate.edu> __| I don't want to listen
http://hermit.reslife.okstate.edu/~jcowan | but it's all too clear...
Computer Engineering Student -- Oklahoma State University -- Stillwater, OK
PGP key available from any PGP keyserver or by fingering the above address.
