From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 06:04:42 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 AE93216A4CE for ; Sat, 18 Sep 2004 06:04:42 +0000 (GMT) Received: from smp500.sitetronics.com (sitetronics.com [82.192.77.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C75443D1D for ; Sat, 18 Sep 2004 06:04:42 +0000 (GMT) (envelope-from dodell@sitetronics.com) Received: from [127.0.0.1] (helo=UebiMiau) by smp500.sitetronics.com with asmtp (Exim 4.24) id 1C8YII-000AGa-OV; Sat, 18 Sep 2004 08:01:58 +0200 Received: from client 82.161.57.57 for UebiMiau2.7 (webmail client); Sat, 18 Sep 2004 8:01:58 -0000 Date: Sat, 18 Sep 2004 8:01:58 -0000 From: "Devon H. O'Dell" To: "Matt Emmerton" , "Mike Meyer" X-Priority: 3 X-Mailer: UebiMiau 2.7.2 X-Original-IP: 82.161.57.57 Content-Transfer-Encoding: 8bit X-MSMail-Priority: Medium Importance: Medium Content-Type: text/plain; charset="iso-8859-1"; MIME-Version: 1.0 Message-Id: X-Mailman-Approved-At: Sat, 18 Sep 2004 15:39:16 +0000 cc: viro@parcelfarce.linux.theplanet.co.uk cc: "freebsd-hackers@freebsd.org"@FreeBSD.ORG cc: "gerarra@tin.it"@FreeBSD.ORG Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Devon H. O'Dell" 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 06:04:42 -0000 --------- 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@. --Devon