Date: Fri, 24 Nov 2006 16:03:56 -0500 From: Bill Moran <wmoran@collaborativefusion.com> To: Erik Trulsson <ertr1013@student.uu.se> Cc: freebsd-security@freebsd.org, Lutz Boehne <lboehne@damogran.de> 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 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 24 Nov 2006 21:41:11 +0100 Erik Trulsson <ertr1013@student.uu.se> 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 <lboehne@damogran.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061124160356.2c215381.wmoran>