[ On Wednesday, December 11, 2002 at 09:34:32 (-0500), Jeff Flowers wrote: ]
> Subject: Dynamically Linked NetBSD-Current
>
> (Personally, I am looking forward to this for security reasons.

Strictly speaking that's backwards.  The way shared libraries are
implemented in *BSD (and SunOS-5, etc.) makes the system overall less
secure in many ways, not more secure.  The primary problem being that
the use of shared libraries suddenly expands the ability of any existing
bug which allowed messing with the stack and/or program counter to one
which is now allowed easy access to any code in any shared library
instead of just the code in the existing binary (eg. system(3) is in the
library and now suddenly with a PC munging bug there's a good chance an
attacker can manipulate the bug into calling system() instead of just
jumping off into hyperspace and crashing the program -- which means if
the process is connected to the net then it's suddenly a potential
remote shell exploit with no need to write shell invoking machine code,
and maybe not even any need to know system-specific details at all (such
as library addresses, etc.) to make a working exploit).

There's also all the security issues related to the actual loading and
binding that has to be done at runtime (never mind all the incredible
performance issues).  There are lots of examples of such bugs already
documented in real-world implementations.  None of those bugs would have
been possible in a static-only environment, not one of them.


> I was
> using OpenBSD a long while ago when a security fix effected a library
> that was also found in a number of the system's statically linked
> binaries. A totally dynamic system would have made that an extremely
> easy fix.)

Don't focus so much on the library code -- while there's lots of it, and
it's often re-used, it's not everything.  Security bugs are likely to
continue to appear just as often in the programs themselves, not the
library code they use (if not more often -- the library code is probably
more often scrutinized by security-aware programmers than much of the
code in the programs themselves).

The only thing that makes bugs in libraries more interesting is that
each use of a buggy routine opens up more possibilities of
vulnerabilities -- that's the nature of sharing, and it's balanced by
the fact that if the source code wasn't shared then fixing a design bug
would be very much harder because many implementations of the same
routines would be spread around everywhere (and there's enough of that
already).

Ultimately it really doesn't matter if you have to replace one binary
file, or a dozen, or all of them to fix a security bug.  At this level
the fixing of security problems by replacing programs or libraries is
supposed to be a mechanical task (and for the most part, it is).  From
the end user's point of view the percieved benefit of fixing dozens of
bugs by replacing one file is completely and totally bogus and
pointless.  Get it out of your head -- it only detracts from the real
issues regarding system maintenance.

Code sharing can only be done _really_ securely in the unix environment
by sharing the source code, not by sharing the object code.  To really
make secure binaries you have to provide 100% of their object code in
their executable image files so that the only other software that's
involved in loading and running them is the kernel itself.

(if memory use of shared code is really that much of a problem then
there are other more secure ways to deal with it....)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>