FreeBSD Kernel buffer overflow

[Matt Emmerton]

----- Original Message ----- 
From: "Devon H. O'Dell" <dodell at sitetronics.com>
To: "Matt Emmerton" <matt at gsicomp.on.ca>; "Mike Meyer" <mwm at mired.org>
Cc: <viro at parcelfarce.linux.theplanet.co.uk>; <gerarra at tin.it>;
<freebsd-hackers at freebsd.org>
Sent: Saturday, September 18, 2004 4:01 AM
Subject: Re: FreeBSD Kernel buffer overflow


> --------- Original Message --------
> From: Matt Emmerton <matt at gsicomp.on.ca>
> To: Mike Meyer <mwm at mired.org>
> Cc: viro at parcelfarce.linux.theplanet.co.uk, gerarra at tin.it,
> freebsd-hackers at freebsd.org
> Subject: Re: FreeBSD Kernel buffer overflow
> Date: 18/09/04 05:41
>
> >
> >
> > ----- Original Message -----
> > From: &quot;Mike Meyer&quot; &lt;mwm at mired.org&gt;
> > To: &quot;Matt Emmerton&quot; &lt;matt at gsicomp.on.ca&gt;
> > Cc: &lt;viro at parcelfarce.linux.theplanet.co.uk&gt;; &quot;Avleen
Vig&quot;
> > &lt;lists-freebsd at silverwraith.com&gt;;
> &lt;freebsd-hackers at freebsd.org&gt;;
> > &lt;gerarra at tin.it&gt;
> > Sent: Saturday, September 18, 2004 1:22 AM
> > Subject: Re: FreeBSD Kernel buffer overflow
> >
> >
> > &gt; In &lt;001801c49d38$1c8cb790$1200a8c0 at gsicomp.on.ca&gt;, Matt
> Emmerton
> > &lt;matt at gsicomp.on.ca&gt; typed:
> > &gt; &gt; I disagree.  It really comes down to how secure you want
FreeBSD
> to be,
> > and
> > &gt; &gt; the attitude of &quot;we don't need to protect against this
case
> because
> > anyone
> > &gt; &gt; who does this is asking for trouble anyway&quot; is one of the
> main reason
> > why
> > &gt; &gt; security holes exist in products today.  (Someone else had
> brought this
> > up
> > &gt; &gt; much earlier on in the thread.)
> > &gt;
> > &gt; You haven't been paying close enough attention to the discussion.
To
> > &gt; exploit this &quot;security problem&quot; you have to be root. If
> it's an
> > &gt; external attacker, you're already owned.
> >
> > I'm well aware of that fact.  That's still not a reason to protect
against
> > the problem.
> >
> > If your leaky bucket has 10 holes in it, would you at least try and plug
> > some of them?
> >
> > --
> > Matt Emmerton
>
> So should we stop the command ``shutdown -h now'' from working for root?
> After all, he can DoS the system with it?
>
> How about this: let's disallow root from loading kernel modules! That way
> this can't ever happen.
>
> Even better: Why don't we just not boot into a usable environment! Then we
> have NO security holes.
>
> You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE
> OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE
ON.
>
> Not to be sarcastic, but you guys are missing the problem. The problem was
> that someone was unaware of a kernel API. When you start programming for
the
> kernel, you need to make sure that the code is secure. If you think this
is
> a problem, take a look at init(8) and learn about securelevels.
>
> What happened: someone was unfamiliar with the syscall API. They crashed
> their system. They screamed wildly, believing they'd found a buffer
> overflow, when they'd merely overloaded the function stack and screwed up
> the call. This caused the system to reboot. Solution: make it more clear
> that syscalls take only 8 arguments. Make it clear that you can pass
> arguments in a struct to a syscall. Make it clear that many/most syscalls
do
> this anyway. If there's beef on this, take it to doc at .

Mike and I discussed this offline.  Can someone just step up to work on and
commit the KASSERT code which handles the problem and end the thread?

The only reason I piped up was because nothing had been done yet, and
suggested two alternate ways of hardening the system that could be
enabled/disabled by the system administrator, instead of being always
enabled (like a KASSERT, which always incurs a run-time check and thus could
hurt performance.)

--
Matt Emmerton