Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!news.radio.cz!newsbastard.radio.cz!news.radio.cz!CESspool!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!ix.netcom.com!news.enteract.com!newsfeed.enteract.com!tqbf From: tqbf@char-star.rdist.org (Thomas H. Ptacek) Newsgroups: comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc,comp.security.unix Subject: Re: *BSD* Security WWW/Mailing List? Date: 24 Apr 1997 00:41:57 GMT Organization: EnterAct, L.L.C. Lines: 78 Message-ID: <slrn5ltb2l.br4.tqbf@char-star.rdist.org> References: <3356E1CC.299E@softway.com.au> <slrn5ll06k.kd3.tqbf@char-star.rdist.org> <5jhur6$51u@innocence.interface-business.de> <slrn5lpvmq.1hm.tqbf@char-star.rdist.org> <5jlr60$f7d@web.nmti.com> Reply-To: tqbf@enteract.com NNTP-Posting-Host: char-star.rdist.org X-Newsreader: slrn (0.9.1.1 BETA UNIX) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.bsdi.misc:6739 comp.unix.bsd.misc:3076 comp.security.unix:33955 23 Apr 1997 20:24:32 GMT peter@nmti.com: >If you're talking about me, no, I haven't said any such thing. I simply said I'm not talking about you. I apologize if you've thought that I was attacking you (I actually have no coherent idea of who you are). >that bugs in the C runtime (and as far as I'm concerned anything that runs >before user-written code gets in control is the same chunk of code... it's This isn't true. On FreeBSD, dynamic linking is implemented through an outside program. When I start a dynamically linked program up, the FreeBSD C runtime library maps in the dynamic linker. A problem in the dynamic linker can thus be resolved by patching the linker. Subsequent calls to dynamically linked programs should then be safe, as they'll map in the patched linker. On the other hand, a problem in the C runtime library itself is not so easily resolved. The obvious issue is that, as an administrator, I have no control over the vulnerability of any program on my system. An unresolveable dynamic linking problem can still be worked around by running the entire system on statically linked binaries. A problem in the C runtime library requires every program on the system to be patched. Extending that point a little further, we need to bear in mind that patching *every binary every compiled on a vulnerable system* is not a small task. The patch itself may be trivial, and because of this, it may seem like patching a dynamic linker is a comparable excercise, but in reality, it takes far more effort to fix the first problem. Of course, the more work involved in fixing a problem, the less likely it is that the problem won't be fixed entirely. It's extremely easy to miss programs when patching everything on the system. >to deal with without fixing the code) are not new. I don't know if SVR4 or >SunOS put the code in "start()" or somewhere else, and I don't care. The FreeBSD doesn't "put the code in start()". FreeBSD calls the code dynamically from start() - the vulnerable library code from the startup_setlocale hole is compiled statically into the C runtime of every binary on the system. These are not identical situations. >security impact is the same, and the exact location of the broken code is >almost irrelevant. The security impact is obviously not the same. A problem in the dynamic linker is resolved by statically linking programs. A problem in the C runtime can only be resolved by modifying code! >Anything that's run with inherited privileges that imports an untrusted >environment needs to be staticly linked. I don't believe anyone's shared Nobody is arguing that point. I agree wholeheartedly. Of course, we're not discussing shared library holes. We're discussing FreeBSD C support holes that affect every binary on the system. >I've been having offline about my comment have brought up some neat hacks >for enhancing as well as "degrading" security. I don't suppose any of those "neat hacks" will be shared with the public? >For the LD_* environment problem, it'd help if it checked whether the >library it was running had the same owner as the euid, or root, if euid EUID checks within library routines are a bad idea. It would help if FreeBSD had an authoritative mechanism to identify programs as "privileged". FreeBSD currently does not. -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));