Bugtraq mailing list archives
Re: a point is being missed
From: fc () all net (Dr. Frederick B. Cohen)
Date: Tue, 21 Nov 1995 10:19:28 -0500
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 amechanism 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
Current thread:
- Re: a point is being missed, (continued)
- Re: a point is being missed Casper Dik (Nov 06)
- Re: a point is being missed Mike Neuman (Nov 08)
- Re: a point is being missed Scott Barman (Nov 08)
- Re: a point is being missed Bruce Montrose (Nov 09)
- Re: a point is being missed System Administrator (Nov 10)
- Re: a point is being missed Dan Stromberg - OAC-DCS (Nov 09)
- Re: a point is being missed Mark D Riggins (Nov 10)
- Re: a point is being missed Casper Dik (Nov 06)
- Re: a point is being missed Dr. Frederick B. Cohen (Nov 21)