oss-sec mailing list archives
Re: Physical access vulnerabilities and auto-mounting
From: Nelson Elhage <nelhage () ksplice com>
Date: Wed, 23 Feb 2011 00:46:47 -0500
I don't have any definite opinions here about where to draw which lines, but I want to point out that in addition to physical attack vectors, virtualization tools are also potentially affected by these kinds of bugs. If you try to mount an untrusted VM's virtual disk image from somewhere, you're also vulnerable to that VM triggering bugs in the filesystem or other layers. - Nelson On Tue, Feb 22, 2011 at 11:17 PM, Dan Rosenberg <dan.j.rosenberg () gmail com> wrote:
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
Current thread:
- Physical access vulnerabilities and auto-mounting Dan Rosenberg (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Eugene Teo (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Eugene Teo (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Steve Grubb (Feb 23)
- Re: Physical access vulnerabilities and auto-mounting Timo Warns (Feb 23)
- Re: Physical access vulnerabilities and auto-mounting Steven M. Christey (Feb 23)
- Re: Physical access vulnerabilities and auto-mounting Nelson Elhage (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Solar Designer (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Michael Tokarev (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Sebastian Krahmer (Feb 22)
- Re: Physical access vulnerabilities and auto-mounting Vincent Danen (Feb 23)
- Re: Physical access vulnerabilities and auto-mounting Hanno Böck (Feb 23)
- Re: Physical access vulnerabilities and auto-mounting Eugene Teo (Feb 22)