[ On Wednesday, March 21, 2001 at 11:42:07 (+1100), Damien Miller wrote: ]
> Subject: Re: getting shared dynamic libraries
>
> On Tue, 20 Mar 2001, Greg A. Woods wrote:
>
> > [ On Tuesday, March 20, 2001 at 12:55:22 (+1100), Damien Miller wrote: ]
> > > Subject: Re: getting shared dynamic libraries
> > >
> > > That is just silly - if someone is in a position to play games with you
> > > system libraries then they can do a lot more damage than that.
> >
> > That's not always true (witness LD_LIBRARY_PATH and the atrocities
> > attributed to its misuse).
>
> LD_LIBRARY_PATH is ignored for setuid apps (like ssh) by any sane OS. If
> an attacker is able to set arbitrary env vars, then you have bigger
> problems than statically linked binaries are going to solve, they could
> just diddle $PATH and point you to a trojan ssh binary for example.
SSH is not entirely a setuid application. In fact now in SSH-2.4.x only
ssh-signer2 is setuid.
While what you say is mostly true for the SSH daemon (because it's
usually started at boot by a root-owned process), there are still lots
of games an attacker can play that could make use of the properties of
dynamic loaders....
> > > Since libc is almost always a dynamic lib, then it makes little sense
> > > to statically link against other things.
> >
> > That's bull. Libc is not always a dynamic library, and it often makes
> > lots of sense to statically link sensitive binaries (be they sensitive
> > in the generic security sense, or only in the sense that they have to be
> > highly available and reliable).
>
> Systems without a dynamic libc generally statically link eveything anyway,
> so this issue is moot.
Excuse me? My systems all have both static and dynamic libraries and
usually give the full ability to statically or dynamically link any
given program that's built on them! All of /bin and /sbin are
statically linked on my systems, while most of /usr/bin and /usr/sbin
are linked dynamically.
All the world's not linux or solaris you know!
> You must have a lot of RAM:
>
> [djm@xenon openssh]$ ls -l ssh ssh.static
> -rwxrwxr-x 1 djm djm 186020 Mar 21 11:43 ssh
> -rwxrwxr-x 1 djm djm 1158408 Mar 21 11:43 ssh.static
The size of the binary file image does not show the real memory
footprint of any program. First off you have to use 'size' to get even
a round number estimate. Secondly you have to examine the actual memory
footprint of both the first process and subsequent instances of it.
Furthermore on all modern unix and unix-like systems the text portion of
all binaries, including static binaries, are shared amongst all
instances of processes loaded from those binaries (and in fact that's
how some dynamic loading systems work too).
Finally you have to consider the mix of processes running on the system
during general use. Shared text means that additional memory used by
library code in static binaries might not add up to any significant
percentage of total memory use on any given general purpose system.
Meanwhile the added resources consumed by ld.so and the various extra
tables necessary to do the run-time linking might be quite significant.
Profiling memory use on unix is never as simple as running "ls -l" (not
even on ancient V7!).
FYI for the first step on NetBSD/i386 with egcs-1.1.2 and '-g -O2':
$ size ssh2.static ssh2.dynamic
text data bss dec hex filename
834671 23000 44252 901923 dc323 ssh2.static
566919 19152 856 586927 8f4af ssh2.dynamic
That's a bit more, but not a terribly large amount more, and most of it
is shared text anyway. (I am curious about the 42k BSS that must be in
some library module.)
> On many systems this won't work properly anyway - Solaris and Linux need to
> be able to dynamically load nss libs etc.
Yeah, but I don't use such stupid and broken systems in any place where
the security of the likes of SSH is necessary. :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
