Skip site navigation (1)Skip section navigation (2)
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>