Re: a point is being missed

[fc () all net (Dr. Frederick B. Cohen)]

> Folks,
>
> [I posted this a week or so ago, but it didn't turn up. :-( ]
>
> A lot of points have been raised by a lot of people, and I think all the
> hoo-ha about static vs. dynamic linking really is missing the point.
> (Makes the subject line appropriate at least!)
>
> Mike Shaver's post got it right (see below), as did Caspers. [IMNSHO]
>
>
> Fact 1: Binaries must be protected against corruption.
>
> Fact 2: Moving part of these binaries (in effect) into dynamic libraries
>         introduces other files which must be protected against corruption.
>
> Fact 3: Maintaining one dynamic library is _FAR_ less overhead than
>         maintaining dozens of independent statically linked binaries which
>         all use a flawed library. The less objects which must be secured,
>         the higher the inherent security and reliability of the solution.
>         (Ask any hardware engineer about the increased reliability of less
>         real estate.)
>
> Fact 4: Dynamic libraries introduces another interface into the "security
>         kernel" which must be understood, maintained and secured.
>
>
> Opinion: [ Actually empirically proven fact IMHO :-) ]
>
> This (securing the dynamic library interface) has not been done adequately
> to date. Ideas such as the HPUX 'chattr' stuff directly address this issue
> at its core. Filtering of LD_* environment variables is band-aid repair to
> a flawed implementation.

I think this issue has been addressed rather directly in the integrity
shell research of the late 1980s.  The basic idea is that the dependency
relationship in systems forms a need for assurance of integrity.  Before
interpreting ANY information, its integrity must be checked in order to
assure the integrity of the processes that interpret/depend on it.  An
implementation was done using cryptographic checksums and has been used
successfully for about 8 years now.  Integrity shells would prevent the
vast majority of attacks we have seen against Unix systems of late.

...
> Case in Point:
>
> Putting statically linked binaries in an anonymous FTP area means that those
> binaries need to be protected against corruption and maintained in the face
> of newly discovered security holes.

With an integrity shell, corrupted versions of these programs could not
be run, and in most cases, would be automatically repaired before
intepretation in order to run with integrity and prevent denial of services.

> Putting dynamically linked binaries and associated libraries means EXACTLY
> THE SAME THING!!! (With the exception of point 4 above.)
>
> Making something statically linked increases the workload and complexity
> of the system, hence inherently LOWERS its security. This can clearly be
> seen by the recent SYSLOG problem which was a security flaw in libc.

This is only true because we lack an underlying integrity protection
mechanism in Unix.  Add integrity shells or another similar system and
this problem goes away.

> Such action is only justified as a work around (read BAND-AID) for an
> inherently insecure dynamic library interface.
>
> As such, we should not be asking the vendors to provide statically linked
> binaries - we should be mandating that they fix the bloody interface!

Or fix the underlying environment so these sorts of problems don't occur.

> Solution Specification:
>
> > From the discussion and discovered flaws, it would appear that we need a
> mechanism to set an attribute on 'security kernel' binaries to disable
> honouring of the LD_* variables. This would appear (IMHO) to be sufficient
> to stop these problems dead. Of course, we still need Tripwire to ensure
> that noone has changed that attribute, but that's another discussion
> entirely. :-)

The solution, in my opinion, is to start thinking about integrity issues
from the design phase.  Every variable, input, and dependency must be
accounted for, the flow of information must be properly controlled, and
the trust we place in each piece of information should be specified,
identified, justified, and removable based on the local policy requirements.

> Challenge:
>
> No doubt there are other problems with this interface that we should also
> look to have addressed.  Why don't we build a list of requirements,
> specify a solution to these problems, and submit this to the vendors? Many
> of the appropriate people are already readers of this list, and I feel
> confident that if we present an achievable solution that it will be
> quickly incorporated into future product.

I believe the solution above would facilitate this.

...
> > From root () iifeak swan ac uk (System Administrator)
> > They could also provide a standard option so that you can pick between
> >
> > 1.      All binaries ignore LD_*
> > 2.      All libraries on LD_* paths must be root or bin owned (id <100 etc)
> > 3.      Existing behaviour.
>
> This is flawed. Not only do you need to protect the libraries, but you
> need to protect the directories which the libraries are located in, and
> any directories in the path from / to those libraries. You must also not
> allow any NFS mounted directories in the path or all bets are off ...
> Looks like there is an infinite number of checks to perform using this
> approach. Look at the underlying paradigm and get that right - don't use
> bandaids.

here here

--
-> See: Info-Sec Heaven at URL http://all.net/
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236