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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ