[72] in WWW Security List Archive
Re: GSS API (as a DLL)...
daemon@ATHENA.MIT.EDU (Rens Troost)
Thu Aug 18 16:35:05 1994
To: Ken Shores <kss1376@pop.draper.com>
Cc: John Ludeman <johnl@microsoft.com>, www-security@ns1.rutgers.edu
In-Reply-To: Your message of "Wed, 17 Aug 1994 21:35:50 EDT."
<199408180136.VAA24832@ns1.rutgers.edu>
Reply-To: rens@imsi.com
Date: Thu, 18 Aug 1994 13:17:44 -0400
From: Rens Troost <rens@imsi.com>
>>>>> "Ken" == Ken Shores <kss1376@pop.draper.com> writes:
Ken> At 03:27 PM 8/17/94 TZ, John Ludeman wrote:
>> ---------- | From: "Alec H. Peterson" <chuckie@panix.com> |
>> Date: Wednesday, August 17, 1994 4:46PM | | Ramin Firoozye
>> writes: | [...] | > | >The BIG problem specific to security
>> DLL's is that someone bent on breaking | >security can write a
>> "wrapper" DLL around a security DLL, store all the | >[...] | |
>> This is one of the reasons why most (if not all) applications
>> that deal with | secure data (like /bin/login and /bin/su) should
>> be statically linked.
>>
>> No, this is not a valid reason. The above argument implies there
>> is no security. If a sysadmin doesn't want this to happen, they
>> must take the appropriate security percautions. If they do not,
>> then *nothing* in the system is secure and any program the system
>> might run can do bad things. This again gets into site security
>> issues which is beyond the topic of this alias.
Ken> I'm inclined to agree. If you can compromise the users loader
Ken> library search path, then you're probably in a position to
Ken> compromise the path used to load applications as well, and
No, he's right. System security things should be statically
linked. Especially on Suns, with their LD_PRELOAD functionality. Most
well written (from a security point of view) software that needs to
exec other stuff will do so with a full pathname, thus defeating any
execlp path manipulation. The load library path remains a
vulnerability.
Ken> anything you could do by wrapping the security services you
Ken> could just do by replacing the client application. Similarly,
Yes, but you don't need write access to /usr/bin or whatever to wrap
the library.
Ken> There are certainly times when dynamic libraries are
Ken> inappropriate, but this doesn't seem to me to be one of them.
It's one of the most important of these times. Take it from me; I've
been burned by this before.
-Rens
