Re: a point is being missed

[geoff () sysadmin com au (Geoff Halprin)]

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.

Indeed, the original "ignore LD_* if EUID!=RUID" is just as flawed a band-aid.
A band-aid solution only creates a false sense of security, as we have seen
when the first LD_* problem came up, leading to login and su being patched,
then seeing the present telnetd version of the problem which directly works
around that patch. (The band-aid appeared because this was the cheapest,
fastest solution to a major hole. No question about the need for this as an
interim measure, but the vendors should have built a more systemic solution
over time.)

Geoff's Law of Entropy: Where there is a security patch there are many new
security holes just waiting to be discovered.

If we are not careful our libraries will start to resemble the tax system;
exceptions upon exceptions upon special cases, all of which makes the
hackers job easier. GO BACK TO BASICS GUYS (vendors).

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.

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.

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!

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.:-)

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.


Disappointment: :-(

I would have hoped that this group could sort out the issues from the
implementation flaws better than most, and we would not see such personal
and emotional arguments being presented. I believe we are all professionals
and all respect each others abilities. Nothing is gained by sinking into
personal attack or company attack. A simple, clear statement of fact and
hypothesis is much more productive! Please keep the signal-to-noise
at a level commensurate with the technical ability this list represents.

I apologise for the strange writing style of this email, but I was in a
strange mood! :^)

[No flames to the list (or me), please! Discussion always welcome though :-)]

> 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.


Cheers,

Geoff


Disclaimer:
    Opinions expressed here-in are not designed, manufactured or intended
    to be used in high risk applications which may, in the event of
    malfunction or error, carry a risk of causing death, injury and/or
    physical and ecomonic losses.  There, that should about cover it! :-)

Copyright:
    (C) Copyright 1995, Geoff Halprin. Microsoft Network is prohibited from
    redistributing this work in any form, in whole or in part, without a
    valid license. License to distribute this post is available to Microsoft
    for AUD$1000. Posting without permission constitutes an agreement to these
    terms.

--------------------------------------------------------------------------------
Geoff Halprin                                  Geoff.Halprin () sysadmin com au
Managing Director                                     Phone: +61-3-9645-8486
The SysAdmin Group Pty Ltd (ACN 069 951 677)          Fax:   +61-3-9686-3399
P.O. Box 441, North Balwyn, 3104                      Mobile: (04) 1930-0827
PGP Fingerprint: (FE349AAD) 05 93 68 35 B2 09 8E 6F  79 8C 16 F8 8F BC 2E CB
--------------------------------------------------------------------------------