User: Password:
|
|
Subscribe / Log in / New account

Physical access vulnerabilities and auto-mounting

From:  Dan Rosenberg <dan.j.rosenberg-Re5JQEeQqe8AvxtiuMwx3w-AT-public.gmane.org>
To:  oss-security-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8-AT-public.gmane.org
Subject:  Physical access vulnerabilities and auto-mounting
Date:  Tue, 22 Feb 2011 23:17:54 -0500
Message-ID:  <AANLkTinj0P1AU31XWEswr+0p0dGHDvPvuTFecMcwQMG2@mail.gmail.com>
Archive-link:  Article

I originally started writing this as a response to the recent CVE
requests for issues in partition handling, but thought it might be a
useful discussion on its own.  I was wondering if there are any
clear-cut policies on issues involving physical access, since these
can be very difficult in terms of assigning blame.

For example, many Linux distributions will auto-mount filesystems on
removable storage, often going so far as to load corresponding kernel
modules for filesystems that aren't compiled in or don't already have
an LKM loaded.  Sometimes, this will happen even if the screen is
locked.

Incidentally, many Linux filesystem implementations don't have
especially robust error handling for failures during attempts to mount
corrupt filesystems.  As an example, I have a deliberately corrupted
btrfs filesystem that triggers a BUG() if you attempt to mount it.  I
formatted a USB stick with this filesystem, so now I have a USB stick
that will panic the kernels of distributions that support
auto-mounting, in some cases even when the screen is locked.

Should this be considered a vulnerability?  Probably.  But what should
be fixed?  Should auto-mounting be disabled entirely?  Is it no longer
a vulnerability if auto-mounting is disabled only when the screen is
locked?  Should all filesystems have graceful error handling for every
possible edge case that can occur when dealing with corruption?

I'd be interested to hear opinions on this.  And depending on how the
discussion goes, I'd be happy to provide more details on specific
cases, such as the btrfs example.

-Dan



(Log in to post comments)

Physical access vulnerabilities and auto-mounting

Posted Feb 24, 2011 2:15 UTC (Thu) by JoeBuck (guest, #2330) [Link]

An auto-mounted disk that allegedly has a filesystem on it should no more crash the system than a file from an unknown source that allegedly has a JPEG image in it. It's data, in some format, meant to be read by software that supports that format.

Physical access vulnerabilities and auto-mounting

Posted Feb 24, 2011 9:07 UTC (Thu) by liljencrantz (guest, #28458) [Link]

This is without a doubt true. On the other hand, we should be very careful about what code we run in kernel space. By making the kernel autoload rarely tested code, such as obscure file systems, in response to actions by a potential attacker significantly increases the possible attack surface. It might not be a vulnerability, but at the very least it is a bad policy.

Physical access vulnerabilities and auto-mounting

Posted Feb 24, 2011 16:42 UTC (Thu) by jthill (subscriber, #56558) [Link]

Should all filesystems have graceful error handling for every possible edge case that can occur when dealing with corruption?
I think that's pretty clearly a "yes".


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds