[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160331165125.GF6207@thunk.org>
Date: Thu, 31 Mar 2016 12:51:25 -0400
From: Theodore Ts'o <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Andreas Dilger <adilger@...ger.ca>,
Yves-Alexis Perez <corsac@...ian.org>,
oss-security@...ts.openwall.com, Theodore Tso <tytso@...gle.com>,
linux-ext4@...r.kernel.org
Subject: Re: CVE Request - Linux kernel (multiple versions)
ext2/ext3 filesystem DoS
On Thu, Mar 31, 2016 at 09:41:28AM -0500, Eric Sandeen wrote:
>
> In the end, errors=panic is really a debug option; a small hoop-jump to
> use it doesn't sound too bad to me.
The problem is that it's not just a debug option. It makes a huge
amount of sense to use this on your root file system, or on any file
system where having the system stagger on after file system errors
have been detected, possibly allowing more data to be corrupted to be
a very bad thing to do. (Example: an ATM machine which uses
remount-ro, and doesn't notice it can no longer update its logs or its
databases, and continues to dispense money....)
On Thu, 31 Mar 2016 08:53:17 -0600, Kurt Seifried wrote:
>The problem is that:
>
>a) means I'll be mounting filesystems with errors that I may want to know
>about (but not have my system panic about)
So mount them with errors=continue or errors=read-only on the command line.
>b) fsck takes a long time on large disks (the smallest size of disk I buy
>for USB drives is 1TB, if I fsck every time I plug one in I'll die of old
>age).
If this is a non-trusted device, then that's the only safe thing to do
--- and even then it's not all that safe. Even though every year or
two someone does run checks to make sure we won't across due to static
fuzzing techniques, I'm fairly certain that if someone was plugging in
a maliciously crafted USB hardware device that was dynamically
changing its data between different read requests, that you could
probably craft a malicious modulation that causes a kernel crash or
worse, some kind of privilege escalation attack.
Of course, it's probably easier to to just create a device that
pretends to be a HID device, so probably the only really sane thing to
do is to epoxy your USB ports.
Ultimately, the real problem is that the Linux kernel doesn't know
whether or not the file system is trusted or not. The decision to
automount comes from userspace, and the kernel doesn't know whether
this is an trusted internal disk, a trusted removeable media which the
user trusts, or some random USB thumb drive that the user picked up
from the parking lot.
To be fair userspace can't really tell the difference between the last
two, so adding hueristics to force a full fsck is going to gore your
particular Ox, but that's the nature of hueristics --- because they
are rules of thumb, inevitably they will get it wrong one way or
another. Profession paranoids, of which this list tends to be
over-represented, will tend to make these tradeoffs in favor of more
security, even if they screw over user convenience. (Such as your
complaining about fsck's taking a long time.)
If we were going to use some hueristic the best I could come up with
might be if the file system was mounted with MS_NOSUID, MS_NODEV, and
MS_NOEXEC, then we should some or all default mount options in the
superblock. I am sure this will still gore somebody's ox, and
arguably the decision to explicitly specifiy errors=remount-ro should
probably be done in the automount daemon, but if that's too hard to
manage, perhaps that's a change kernel developers could make to the
component which is under our control.
This is really a system-level problem, though, for which putting epoxy
in the USB ports might actually be the more general solution. It
certainly is the more secure option. :-)
- Ted
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
