Bugtraq mailing list archives
Re: a point is being missed
From: geoff () sysadmin com au (Geoff Halprin)
Date: Tue, 21 Nov 1995 22:16:14 +1100
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 --------------------------------------------------------------------------------
Current thread:
- Re: a point is being missed, (continued)
- Re: a point is being missed der Mouse (Nov 04)
- 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 der Mouse (Nov 04)
- Re: a point is being missed Dr. Frederick B. Cohen (Nov 21)