From owner-freebsd-security@FreeBSD.ORG Fri Nov 24 21:04:16 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2555716A412 for ; Fri, 24 Nov 2006 21:04:16 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6622443D46 for ; Fri, 24 Nov 2006 21:03:14 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from working (c-71-60-174-60.hsd1.pa.comcast.net [71.60.174.60]) (AUTH: LOGIN wmoran, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 24 Nov 2006 16:03:57 -0500 id 00056426.45675E3D.00010644 Date: Fri, 24 Nov 2006 16:03:56 -0500 From: Bill Moran To: Erik Trulsson Message-Id: <20061124160356.2c215381.wmoran@collaborativefusion.com> In-Reply-To: <20061124204111.GA3431@owl.midgard.homeip.net> References: <45656A3B.6000000@zedat.fu-berlin.de> <20061123213656.GA26275@walton.maths.tcd.ie> <200611231742.01418.josh@tcbug.org> <4567504E.6040601@damogran.de> <20061124151543.03f06b19.wmoran@collaborativefusion.com> <20061124204111.GA3431@owl.midgard.homeip.net> Organization: Collaborative Fusion Inc. X-Mailer: Sylpheed version 2.2.9 (GTK+ 2.10.6; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Lutz Boehne Subject: Re: UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2006 21:04:16 -0000 On Fri, 24 Nov 2006 21:41:11 +0100 Erik Trulsson wrote: > On Fri, Nov 24, 2006 at 03:15:43PM -0500, Bill Moran wrote: > > On Fri, 24 Nov 2006 21:04:30 +0100 > > Lutz Boehne wrote: > >=20 > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > >=20 > > > > Out of the box you need to be root to mount things. Once you have= =20 > > > > root access to a box you don't need silly things like this to crash= =20 > > > > it. > > > >=20 > > > > If you've gone out of your way to configure your box in such a way= =20 > > > > that a non-root user can mount arbitrary UFS filesystems then they= =20 > > > > certainly don't need to waste their time with buffer-overflows and= =20 > > > > the like. They can simply mount a filesystem with any number of SU= ID=20 > > > > root binaries on it and have their way with the box. > > > >=20 > > > > Either way, while it's senseless to argue that the buffer overflows= =20 > > > > don't exist, anyone in a positiion to actually exploit them doesn't= =20 > > > > need them to be malicious. > > >=20 > > > I do quite not agree with your analysis. > > >=20 > > > Firstly, if you set the vfs.usermount sysctl to 1, users can mount any > > > filesystem from a device they have read access to to any directory th= ey > > > own, _but_ if the user does so, FreeBSD will automatically mount that > > > filesystem nosuid. So the intent is to give a local user the possibil= ty > > > to mount a filesystem without gaining full control over the machine. > > >=20 > > > Secondly, why would people go out of their way to set that sysctl to = 1? > > > I can see this happen in environments where users are not supposed to > > > have full control over their desktop machines, but where they need to > > > transfer data to/from USB flash drives. > > >=20 > > > Thirdly, while I'm talking about desktop machines, many desktop Linux > > > distributions are configured such they will _automatically_ mount USB > > > media once those are plugged in (and pop up an icon on the KDE or GNO= ME > > > desktop). It's only a matter of time until such functionality will be > > > available on FreeBSD (maybe it already is?) and widely used on desktop > > > machines (e.g. on Laptops, in Internet Cafes), as it seems to be quite > > > user friendly. On such machines an attacker would not even need a loc= al > > > user account. > > >=20 > > > While one might say that these attack scenarios all require physical > > > access (and we all know that physical access is game over, right;)), > > > simply plugging in a USB memory device is much more inconspicious than > > > other "physical" attacks, like rebooting a box into single user mode > > > (which one could additionally secure with a password prompt). > >=20 > > I don't think anyone is arguing whether or not this is a bug. It is. > >=20 > > I will argue, however, that it does not constitute a security flaw, whi= ch > > is what the MOKB folks claim. If a user has the ability to graft untru= sted > > filesystems onto the filesystem tree, that user is in one of a few scen= erios: > > 1) They are root or equivalent. > > 2) They have physical access to the machine. > > 3) They are working on a machine that is secured incorrectly. > >=20 > > If #1, then it's a mute point, as root can DOS a machine without any ke= rnel > > bugs. If #2, it's a mute point, as physical access bypasses any softwa= re > > security anyway. >=20 > That is not really true. =20 >=20 > *Unlimited* physical access can get you around any > software security, but an attacker often does not have unlimited physical > access. =20 >=20 > Take for example public computers in a library or an internet caf=E9 > or similar (or just a computer room in a school.) A user there can proba= bly > try to mount a CD-ROM or a floppy or a USB-stick without anybody noticing= or > caring much if they do notice. If that same user were instead to remove = the > case to put in his own harddisk to use as a boot device, then it is very > likely that somebody will investigate what said user is doing. An attacker could insert a Knoppix or FreeSBIE disk and get better access t= han this bug will give him. The bug doesn't give any privilidges, it simply ca= uses a kernel panic. But let's say a user _does_ attempt to exploit this. He inserts a malicious jump drive, mounts and the system panics. He can then ... what? What has been accomplished? The system boots back up and, if he desires, he can pan= ic it again and again until somebody notices. So what? I think a lot of people forget that a kernel panic is an intentional action that the kernel takes to protect itself from possible damage. Anything that causes a kernel panic is not a security flaw, it's a security _FEATURE_ as the programming bug can not be used for further exploit the system. So, the fact that the system panics demonstrates that there _is_no_security_problem= _. The system intentionally shuts itself down to protect itself. > There is also the fact to consider that the more powerful attack vectors > that physical access opens up tend to take a bit of time to use. > If it takes 10 minutes to open a case and modify the innards then it is n= ot > possible to get access undetected while the rightful user goes to another > room to fetch something (for example.) If it takes 10 seconds to mount an > USB stick and get root through some filesystem bug then you can do it whi= le > somebodys back is turned. True. But you can't get root through that filesystem bug, you can only pan= ic the system, so your point isn't relevent. > > And #3 is a mute point, since any system can be configured > > to be insecure by a properly skilled idiot, and the kernel hackers can'= t be > > expected to program around idiotic sysadmins. > >=20 > > So, yes, it is a bug that needs to be fixed. But I don't see it as a s= ecurity > > issue. >=20 > It is a security issue, but perhaps not one of the most critical ones (in > particular it does not allow remote breakins which are generally the most > worrisome kind.) I still disagree. As stated in the alert, the bug causes a kernel panic. = There is no root access provided by the bug, so it doesn't give you any more of a security problem than pressing the power button or pulling the cord from th= e wall would. -Bill