From owner-freebsd-security Mon Feb 3 08:22:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id IAA05632 for security-outgoing; Mon, 3 Feb 1997 08:22:34 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA05626 for ; Mon, 3 Feb 1997 08:22:29 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id RAA29396; Mon, 3 Feb 1997 17:19:31 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id RAA01619; Mon, 3 Feb 1997 17:21:24 +0100 (MET) Message-Id: <3.0.32.19970203172123.00b499e0@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 03 Feb 1997 17:21:24 +0100 To: tqbf@enteract.com From: Eivind Eklund Subject: Re: Critical Security Problem in 4.4BSD crt0 Cc: phk@critter.dk.tfs.com (Poul-Henning Kamp), dg@root.com, torbjorn@norway.eu.net, freebsd-security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 07:42 AM 2/3/97 -0600, Thomas H. Ptacek wrote: >This thread really isn't going anywhere. My concrete suggestion is that >you release security announcements as soon as you become aware of a >security problem with your code, whether you found it or someone else did. > >If there's something I can do to help ensure that this happens, let me >know. There is. I've just joined the FreeBSD commit team with the explict purpose of doing proactive security reviews; however, I'm just going to quietly patch all problems I find that _seems like_ they could be security holes. I'm not going to actually run through a setuid program and verify that there is a way to get user data to a potential buffer overflow - I'll just add checks to make sure that the buffer overflow can never happen. If you feel like actually checking which of the things I fix is a security hole (and somebody some committer know can vouch that you aren't one of these dangerous hackers :) I can throw the patches in your direction and let you write an advisory _for those that turn out to be actual holes_. That means that for eg a buffer overflow, you should prove, either by logic or by demonstration, that one can make this buffer overflow as a user. I'm reasonably certain I can make them get published :) Personally I feel that my time is more efficiently spent on finding and fixing more bugs, rather than publishing advisories. There are some very effective ways of finding potential buffer overflows and other "standard holes", though I haven't seen anything indicating that there are any significant amount of hackers using them. I think we would see more breakins by actually making public where to look. >> Some of them, but remember that there is also a great deal of misguided >> youth out there. > >Perhaps I have a bit more experience dealing with the "misguided youth" >combing FreeBSD code than you do. Perhaps not. If I had to place a bet on >whether the FreeBSD project or the underground had any particular bug, I >would almost always put my money on the underground. As a former member of the underground I would tend to disagree; things seem to pop up on bugtraq almost as fast as there is an exploit for them these days. And that isn't all that fast, either. >Again, my complaint is simply that prior experience has shown that >security-related problem reports do not elicit announcements from the >FreeBSD team to their users. I think this is wrong. In most cases, these >problem reports affect many, many people running older versions of your >operating system. As long as they're on the FTP site, they're supported. I've been thinking about setting up a mailing list for distributing binary patches; this would require some VERY tight security for how those patches are sent and accepted, though. (I've been thinking along the lines of PGP-signing from two different core team members with their keys on very different machines.) This could even be used to throw out patches _without_ telling what the problem was. >> How about this: If you find a hole, you send us a patch, and if we >> do not fix it within a particular period (two weeks ?) you can post it >> to the world ? > >Two weeks? > >You think a vulnerability window of (at least) two weeks is acceptable? No. But neither is breaking the systems. Or making the systems of the less security-conscious sysadmins much _more_ vulnerable by telling everybody about the problem. The problem is that there are no acceptable solutions for this, so we just have to find the least distasteful of them. >I'd just as soon post it to the world immediately, so affected systems >could get themselves patched. That's me, though. What would require a two >week delay? Anything the obvious patch would break would be worth breaking >to maintain security; you can release an "official, effective" patch later >on and treat the initial one as a workaround. Two weeks isn't something we will need in most cases - but it is something that might be needed in _some_ cases. >I think silent fixes are bad. I think every time you find a problem and >silently fix it, you ignore the possibility that criminals on the network >already found and are exploiting the problem - you're thus potentially >allowing systems to be broken into. I'd much rather have to wade through >your dirty laundry than see my systems broken into simply because I didn't >have the time to keep -current. What about those that don't have time to even keep -stable? Eivind Eklund / perhaps@yes.no / http://maybe.yes.no/perhaps/