UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824, MOKB-03-11-2006, CVE-2006-5679

[Bill Moran]

On Fri, 24 Nov 2006 21:41:11 +0100
Erik Trulsson <ertr1013 at 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 at damogran.de> wrote:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > > Out of the box you need to be root to mount things.  Once you have 
> > > > root access to a box you don't need silly things like this to crash 
> > > > it.
> > > > 
> > > > If you've gone out of your way to configure your box in such a way 
> > > > that a non-root user can mount arbitrary UFS filesystems then they 
> > > > certainly don't need to waste their time with buffer-overflows and 
> > > > the like.  They can simply mount a filesystem with any number of SUID 
> > > > root binaries on it and have their way with the box.
> > > > 
> > > > Either way, while it's senseless to argue that the buffer overflows 
> > > > don't exist, anyone in a positiion to actually exploit them doesn't 
> > > > need them to be malicious.
> > > 
> > > I do quite not agree with your analysis.
> > > 
> > > 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 they
> > > own, _but_ if the user does so, FreeBSD will automatically mount that
> > > filesystem nosuid. So the intent is to give a local user the possibilty
> > > to mount a filesystem without gaining full control over the machine.
> > > 
> > > 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.
> > > 
> > > 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 GNOME
> > > 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 local
> > > user account.
> > > 
> > > 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).
> > 
> > I don't think anyone is arguing whether or not this is a bug.  It is.
> > 
> > I will argue, however, that it does not constitute a security flaw, which
> > is what the MOKB folks claim.  If a user has the ability to graft untrusted
> > filesystems onto the filesystem tree, that user is in one of a few scenerios:
> > 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.
> > 
> > If #1, then it's a mute point, as root can DOS a machine without any kernel
> > bugs.  If #2, it's a mute point, as physical access bypasses any software
> > security anyway.
> 
> That is not really true.  
> 
> *Unlimited* physical access can get you around any
> software security, but an attacker often does not have unlimited physical
> access.  
> 
> Take for example public computers in a library or an internet café
> or similar (or just a computer room in a school.)  A user there can probably
> 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 than
this bug will give him.  The bug doesn't give any privilidges, it simply causes
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 panic
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 not
> 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 while
> somebodys back is turned.

True.  But you can't get root through that filesystem bug, you can only panic
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.
> > 
> > So, yes, it is a bug that needs to be fixed.  But I don't see it as a security
> > issue.
> 
> 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 the wall
would.

-Bill