oss-sec mailing list archives
Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS
From: Andreas Dilger <adilger () dilger ca>
Date: Thu, 31 Mar 2016 09:47:34 -0600
On Mar 31, 2016, at 8:53 AM, Kurt Seifried <kseifried () redhat com> wrote:
On Wed, Mar 30, 2016 at 2:43 PM, Theodore Ts'o <tytso () mit edu> wrote:You can mount the file system with "mount -o errors=continue" and this will override the default behavior specified in the super block. I would argue that a Desktop or server system that had automount should either (a) mount with -o errors=continue, or (b) force an fsck on the file system before mounting it.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) 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).
Two options that I think are fairly straight forward to fix this: - add /sbin/mount.{ext2,ext3,ext4} helpers that add "errors=remount-ro" when a non-root user mounts the filesystem. I think "errors=remount-ro" is safer than "errors=continue" since it blocks all later attempts to modify the filesystem, otherwise there may be further corruption and more risk of hitting an unhandled error condition. - add a check in ext4_fill_super() to change EXT4_ERRORS_PANIC superblock option to EXT4_ERRORS_RO if mounted by a non-root user
So I think this is a particularly meaningless CVE, which is why I have zero respect for people who try to make any kind of conclusion based on CVE counts. I certainly don't plan to do anything about this.As for your comments on CVE counting even the then head of CVE @mitre told people not to rely on CVE counting for vulnerability stats: https://media.blackhat.com/us-13/US-13-Martin-Buying-Into-The-Bias-Why-Vulnerability-Statistics-Suck-Slides.pdf As for your comment on not fixing this: I think fundamentally I should be able to plug a file system in and try to mount it with default/reasonable options and NOT have my system panic. File system handling code, like any code that handles user supplied data should be able to handle garbage gracefully and securely. At worst it should try to mount and go "derp, it's messed up, maybe fsck it?"
I think this is a legitimate problem to fix. The main question is how complex it is to fix? I just don't know enough about the increasing number of ways that userspace can mount a filesystem to know how to detect this correctly in the kernel. It may be that "non-root user" in the options above should be "removable media" instead? Knowing the intent of the user/sysadmin is difficult. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
Current thread:
- CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Hugues ANGUELKOV (Mar 29)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Yves-Alexis Perez (Mar 29)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Andreas Dilger (Mar 29)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Theodore Ts'o (Mar 30)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Eric Sandeen (Mar 31)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Theodore Ts'o (Mar 31)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Kurt Seifried (Mar 31)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Andreas Dilger (Mar 31)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Andreas Dilger (Mar 29)
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Yves-Alexis Perez (Mar 29)
- <Possible follow-ups>
- Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS Hugues ANGUELKOV (Mar 31)