Re: Bugs involving maliciously crafted file system

[Dave Chinner]

On Wed, May 23, 2018 at 07:41:15PM -0400, Theodore Y. Ts'o wrote:
> On Wed, May 23, 2018 at 01:01:59PM -0500, Eric Sandeen wrote:
> > 
> > What I'm personally hung up on are the bugs where the "exploit" involves merely
> > mounting a crafted filesystem that in reality would never (until the heat death
> > of the universe) corrupt itself into that state on its own; it's the "malicious
> > image" case, which is quite different than exposing fundamental bugs like the
> > SB_BORN race or or the user-exploitable ext4 flaw you mentioned in your reply.
> > Those are more insidious and/or things which can be hit by real users in real life.
> 
> Well, it *can* be hit in real life.  If you have a system which auto
> mounts USB sticks, then an attacker might be able to weaponize that
> bug by creating a USB stick where mounted and the user opens a
> particular file, the buffer overrun causes code to be executed that
> grabs the user's credentials (e.g., ssh-agent keys, OATH creds, etc.)
> and exfiltrates them to a collection server.

We've learnt this lesson the hard way over and over again: don't
parse untrusted input in privileged contexts. How many times do we
have to make the same mistakes before people start to learn from
them?

User automounting of removable storage should be done via a
privilege separation mechanism and hence avoid this whole class of
security problems. We can get this separation by using FUSE in these
situations, right?

> Fedora and Chrome OS might be two such platforms where someone could
> very easily create a weaponized exploit tool where you could insert a
> file system buffer overrun bug, and "hey presto!" it becomes a serious
> zero day vulnerability.

There's little we can do to prevent people from exploiting
flaws in the filesystem's on-disk format. No filesystem has robust,
exhaustive verification of all it's metadata, nor is that
something we can really check at runtime due to the complexity
and overhead of runtime checking.

And then when you consider all the avenues to data exposure and
unprivileged runtime manipulation of on-disk metadata (e.g.
intentionally cross linking critical metadata blocks into user
data files), it's pretty obvious that untrusted filesystem images
are not something that should *ever* be parsed in a privileged
context.

> (I recently suggested to a security researcher who was concerned that
> file system developers weren't taking these sorts of things seriously
> enough could do a service to the community by creating a demonstration
> about how these sorts of bugs can be weaponized.  And I suspect it
> could be about just as easily on Chrome OS as Fedora, and that can be
> one way that an argument could be made to management that more
> resources should be applied to this problem.  :-)

There's "taking it seriously" and then there's "understanding that
we can't stop new exploits from being developed because they
exploit a flaw in the trust model".

i.e. kernel filesystems are built on a directly connected trust
model where the storage "guarantees" it will return exactly what the
filesystem has stored in it.  Hence our filesystems are not built
around tamper-evident/tamper-proof structures and algorithms that
are needed to robustly detect 3rd-party manipulation because their
trust model says they don't need to defend against such attacks.

As such, the most robust way I can see of defending *the kernel*
against malicious/untrusted filesystem images is to move parsing of
those images out of the kernel privilege context altogether. The
parser can then be sandboxed appropriately as you suggested and
we've avoided the problem of kernel level exploits from malicious
filesystem images....

> Of course, not all bugs triggered by a maliciously crafted file system
> are equally weaponizable.  An errors=panic or a NULL derefrence are
> probably not easily exploitable at all.

Bugs don't have to be exploitable to be a "security issue". Detected
filesystem corruptions on a errors=panic mount, or undetected
problems that cause a x/NULL deref are still a user-triggerable
kernel crash (i.e. a DOS) and therefore considered a security
problem.

> A buffer overrun (and I fixed
> two in ext4 in the last two days while being stuck in a T13 standards
> meeting, so I do feel your pain) might be a very different story.

The fact you are currently finding and fixing buffer overuns in ext4
solidly demonstrates my point about existing filesystems being
largely untrustable and unfixable. :/

Cheers,

Dave.


-- 
Dave Chinner
david@xxxxxxxxxxxxx