Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Feb 1997 17:21:24 +0100
From:      Eivind Eklund <eivind@dimaga.com>
To:        tqbf@enteract.com
Cc:        phk@critter.dk.tfs.com (Poul-Henning Kamp), dg@root.com, torbjorn@norway.eu.net, freebsd-security@FreeBSD.ORG
Subject:   Re: Critical Security Problem in 4.4BSD crt0
Message-ID:  <3.0.32.19970203172123.00b499e0@dimaga.com>

next in thread | raw e-mail | index | archive | help
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/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970203172123.00b499e0>