FreeBSD Kernel buffer overflow

[Matt Emmerton]

> On Fri, Sep 17, 2004 at 07:52:18PM -0700, Avleen Vig wrote:
> > The difference is, that calling panic(9) is not a bug, it's a designed
> > mechanism to panic a kernel.
> > The behaviour reported is NOT designed behaviour (at least, no-one has
> > said it is).
> >
> > Therefore, if the man wants to write a patch to fix unintended
> > behaviour, what's wrong with that?
>
> Extra code on a time-critical path with no sane use whatsoever.  Note
> that anyone who adds a syscall (or a library function, for that matter)
> with that many arguments deserves public humiliation for terminal lack
> of taste, so it's not going to help anything that wouldn't be worth
> rm -rf...

I disagree.  It really comes down to how secure you want FreeBSD to be, and
the attitude of "we don't need to protect against this case because anyone
who does this is asking for trouble anyway" is one of the main reason why
security holes exist in products today.  (Someone else had brought this up
much earlier on in the thread.)

An article posted today on Slashdot (
http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html )
points out that this attitude as a key reason why OSS code isn't
neccessarily more secure than commercial counterparts, even though there are
more eyes on the source.

We have to realize the fact that there *are* insecure FreeBSD installations
out there, and because of the OSS nature of FreeBSD, the availability of the
source code and public mailing lists like this one (which highlight possible
security holes) makes the development of exploits much, much easier.

The argument of "extra code on a time-critical path" is valid, but only if
we're concerned about building the fastest BSD out there. However, we can
provide a choice to system administrators by wrapping these sanity checks
with a runtime if-check of a sysctl value, or a compile-time #define, much
like we use for WITNESS or INVARIANTS today.

I'm reminded of the old adage of "good, fast, cheap -- choose two".  There's
nothing preventing us from implementing all three and leaving the choice of
which two to use up to the end-user.

--
Matt Emmerton