From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 07:25:55 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061CD16A4CE for ; Sat, 18 Sep 2004 07:25:55 +0000 (GMT) Received: from skippyii.compar.com (ns1.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AF0E43D41 for ; Sat, 18 Sep 2004 07:25:54 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i8I7VJs9049656; Sat, 18 Sep 2004 03:31:20 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002001c49d50$540e8a00$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Devon H. O'Dell" , "Mike Meyer" References: Date: Sat, 18 Sep 2004 03:22:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: viro@parcelfarce.linux.theplanet.co.uk cc: gerarra@tin.it cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 07:25:55 -0000 ----- Original Message ----- From: "Devon H. O'Dell" To: "Matt Emmerton" ; "Mike Meyer" Cc: ; ; Sent: Saturday, September 18, 2004 4:01 AM Subject: Re: FreeBSD Kernel buffer overflow > --------- Original Message -------- > From: Matt Emmerton > To: Mike Meyer > Cc: viro@parcelfarce.linux.theplanet.co.uk, gerarra@tin.it, > freebsd-hackers@freebsd.org > Subject: Re: FreeBSD Kernel buffer overflow > Date: 18/09/04 05:41 > > > > > > > ----- Original Message ----- > > From: "Mike Meyer" <mwm@mired.org> > > To: "Matt Emmerton" <matt@gsicomp.on.ca> > > Cc: <viro@parcelfarce.linux.theplanet.co.uk>; "Avleen Vig" > > <lists-freebsd@silverwraith.com>; > <freebsd-hackers@freebsd.org>; > > <gerarra@tin.it> > > Sent: Saturday, September 18, 2004 1:22 AM > > Subject: Re: FreeBSD Kernel buffer overflow > > > > > > > In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt > Emmerton > > <matt@gsicomp.on.ca> typed: > > > > 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.) > > > > > > You haven't been paying close enough attention to the discussion. To > > > exploit this "security problem" you have to be root. If > it's an > > > 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@. 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