Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!su-news-feed4.bbnplanet.com!news.bbnplanet.com!coop.net!pacifier!deraadt From: deraadt@theos.com (Theo de Raadt) Newsgroups: comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc,comp.security.unix Subject: Re: *BSD* Security WWW/Mailing List? Date: 21 Apr 1997 01:55:00 GMT Organization: Pacifier BBS, Vancouver, Wa. ((360) 693-0325) Lines: 131 Message-ID: <DERAADT.97Apr20195500@zeus.pacifier.com> References: <3356E1CC.299E@softway.com.au> <DERAADT.97Apr18181055@zeus.pacifier.com> <5jdgaf$34i@cynic.portal.ca> <DERAADT.97Apr20113509@zeus.pacifier.com> <5jeb2b$ata@cynic.portal.ca> NNTP-Posting-Host: zeus.theos.com In-reply-to: cjs@cynic.portal.ca's message of 20 Apr 1997 17:06:35 -0700 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.bsdi.misc:6687 comp.unix.bsd.misc:3024 comp.security.unix:33773 In article <5jeb2b$ata@cynic.portal.ca> cjs@cynic.portal.ca (Curt Sampson) writes: > As has OpenBSD. Although I notice your FTP server still has no way > of doing anonymous uploads that are secure from abuse by warez-traders. I am not pointing this out to get into a spitting match; I'm pointing this out to show that you too have holes that are not closed, Theo. Please describe a hole that can be fixed in _software_. Putting a writeable directory in your anonftp directory is a system admin error. Of course, since you have the ftp bounce attack in your ftp daemon, it's a hell of a lot worse of a problem for you! By the way Curt -- what is your solution? I see no fix for this in the NetBSD ftpd. You regularly insinuate that you have fixed holes that others haven't, but you never describe the exact holes you fix: you just say `look at our change logs,' which don't describe the attacks at all. Go read bugtraq. Through postings made by Secure Networks (our friends) we have made the world aware of a number of problems. But come on. Without a proper analysis of the attacks, which you refuse to provide, there's no real evidence that many of the things you have `fixed' were ever broken. HAHAHAHA! `proper analysis'. Hahahahahaha. We find a buffer overflow. We fix it. We don't _CARE_ if it is exploitable; we just fix it. Sometimes we later find it is exploitable. Sometimes it's immediately evident. Sometimes it is just a bug that I can SIGSEGV a program with. Know what? I hate core files lying around my machine too. But I guess I should be doing some `proper analysis' before fixing those. Curt, you're way out there! Let me provide one of my favorite examples. In August I went over lpr.c with Todd and we fixed a couple of buffer overflows. None of us checked for exploitability (see, sometimes we do, sometimes we don't). Then we shipped our 2.0 release. Ho hum, time passed as it tends to. About 4 months later someone posted an article to Bugtraq. It included source to an exploit. Wham, root. Neat. We had shipped a release months earlier. We didn't have the hole! I saw the exploit code and I had to ASK the author if it still worked in OpenBSD, because I thought it was a new one! It wasn't a new hole. We had it fixed. (The exploit author was actually a little bit upset that he hadn't been the first to find it ;-) There are many other examples. In essence we are fixing holes before they become KNOWN holes. That is what being CAREFUL is all about. Obviously you know zero about how an operating system becomes secure. Through diligence and paranoia, by fixing BUGS OF ALL KINDS. I invite you to step onto the podium and suggest that going through the source tree carefully looking for problem areas and fixing them isn't going to close a few holes. Or a lot of holes. To be honest, it's a lot of holes. They fall into classes, and in some classes like mktemp there are perhaps 500 in the tree, of which perhaps one quarter are exploitable for some nasty effect. One was so nasty that a BSDi person got extremely upset that we hadn't told them beforehands. Heh, that /etc/security bug sure was funny. I presume you have it fixed, right? But now, if you'd rather chat about security problems before they hit you in the face, hey, all I can suggest is you start running your backups more often. I certainly am not going to waste my time talking to anyone with such a careless attitude towards fixing problems which are primarily just simple bugs with bad and `exploitable' side effects. Fixing a buffer overflow or a writable directory race isn't rocket science! >And the source routing controls in the kernel appear >completely insufficient compared to the threat. A typical insinuation. What exactly does the OpenBSD kernel do with source routed packets that the NetBSD kernel doesn't, Theo? It drops them dead, and it bitches too. Always. It won't forward them and it won't accept them. And if you are silly enough to ask the kernel to let them through, a bunch of applications have been carefully modified (AND FIXED if they did it wrong, grr, including sendmail, hint, hint) to specifically and carefully deal with them. Is your rshd safe? Did you not see the posting about Neils Provos' new source routing attack? The secnet posting about the new source routing attack mentioned a few definately vulnerable programs but didn't mention anything about other possible programs which might be. Hmm, I wonder if there are any. Do you feel safe? >I look forward to the day we are able to look at cvs logs for the >NetBSD source tree! So do we all. But I think that's been gone over already. Let's go over it again. There are two possible reasons why NetBSD doesn't make their CVS tree available to the public like all the other free OS groups do (OpenBSD, FreeBSD, Linux to a limited extent too now) 1. Either they have bad things in there. 2. Or they don't want to let it out of their grubby hands. Are there any other reasons? Oh right -- there's a pr1v4t3 reason and there is a s3cr3t document with USL! Some free operating system. >The fixes are there, and they are shared with the world. The fixes are not as important as proper descriptions of the problem, Theo. It's very difficult to work back to the original problem from your fix, and thus even more difficult to verify that your fix is correct. Balony. You are making a fool of yourself. The fixes are clearly more important. You are too lazy to read the diffs, and you would like to blame us for your slackness. -- This space not left unintentionally unblank. deraadt@openbsd.org www.OpenBSD.org -- We're fixing security problems so you can sleep at night. (If it wasn't so fascinating I might get some sleep myself...)