Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]

[dropping MITRE from CC since it's not about the CVE]
[adding ext and Theodore to CC]

On mar., 2016-03-29 at 19:24 +0200, Hugues ANGUELKOV wrote:
> Hello,
> 
> The linux kernel is prone to a Denial of service when mounting specially
> crafted ext2/ext3 (possibly ext4) filesystems. This occurs in the function
> ext4_handle_error who call the panic function on precise circumstance.

Did you contact the upstream maintainers about this? I'm adding them just in
case they're not already aware of that…

> This was tested on severals linux kernel version: 3.10, 3.18, 3.19, on
> real hardware and Xen DomU PV & HVM (the crash report attached is from a
> Fedora 3.18 PV DomU), from different distribution release: Ubuntu, CentOS,
> Fedora, Linux Mint, QubesOS.
> This a low security impact bug, because generally only root can mount
> image, however on Desktop (or possibly server?) system configured with
> automount the bug is easily triggable (think of android smartphone?Haven't
> test yet).
> The crafted image may be burn onto SD card or USB key to crash a large
> panel of linux box.
> 
> 
> [ 929.200197] EXT4-fs error (device loop0): ext4_iget:4058: inode #2: comm
> mount: bad extended attribute block 8390656
> [ 929.200226] Kernel panic - not syncing: EXT4-fs (device loop0): panic
> forced after error
> [ 929.200226]
> [ 929.200230] CPU: 1 PID: 980 Comm: mount Tainted: G O
> 3.18.17-8.pvops.qubes.x86_64 #1
> [ 929.200233] 0000000000000000 000000007533690c ffff88000ea07aa8
> ffffffff81722191
> [ 929.200237] 0000000000000000 ffffffff81a84108 ffff88000ea07b28
> ffffffff8171a462
> [ 929.200240] ffff880000000010 ffff88000ea07b38 ffff88000ea07ad8
> 000000007533690c
> [ 929.200244] Call Trace:
> [ 929.200249] [<ffffffff81722191>] dump_stack+0x46/0x58
> [ 929.200253] [<ffffffff8171a462>] panic+0xd0/0x204
> [ 929.200257] [<ffffffff812ae4d6>] ext4_handle_error.part.188+0x96/0xa0
> [ 929.200260] [<ffffffff812ae838>] __ext4_error_inode+0xa8/0x180
> [ 929.200264] [<ffffffff81292869>] ext4_iget+0x929/0xae0
> [ 929.200267] [<ffffffff812b31fb>] ext4_fill_super+0x18db/0x2b60
> [ 929.200270] [<ffffffff8120af20>] mount_bdev+0x1b0/0x1f0
> [ 929.200273] [<ffffffff812b1920>] ? ext4_calculate_overhead+0x3d0/0x3d0
> [ 929.200276] [<ffffffff812a3425>] ext4_mount+0x15/0x20
> [ 929.200278] [<ffffffff8120b879>] mount_fs+0x39/0x1b0
> [ 929.200282] [<ffffffff811afd95>] ? __alloc_percpu+0x15/0x20
> [ 929.200285] [<ffffffff8122754b>] vfs_kern_mount+0x6b/0x110
> [ 929.200287] [<ffffffff8122a38c>] do_mount+0x22c/0xb60
> [ 929.200290] [<ffffffff811aab96>] ? memdup_user+0x46/0x80
> [ 929.200292] [<ffffffff8122b002>] SyS_mount+0xa2/0x110
> [ 929.200295] [<ffffffff8172a609>] system_call_fastpath+0x12/0x17
> [ 929.200301] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation
> range: 0xffffffff80000000-0xffffffff9fffffff)c
> 
> I cannot attach the PoC (2x2MB too large) nor sending it in plain text
> (they are filesystems), so I've uploaded it on this website of free file
> sharing ... (sorry for the inconvenient):
> poc.ext2 https://1fichier.com/?zbk2gohk8s
> poc.ext3 https://1fichier.com/?9r0c8agjfa
> 
> Can you assign a CVE for this?
> Thank for reading and your time.
> 
> Hugues ANGUELKOV.
> 
> 
-- 
Yves-Alexis


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 4043 bytes --]

On Mar 29, 2016, at 3:14 PM, Yves-Alexis Perez <corsac@debian.org> wrote:
> 
> [dropping MITRE from CC since it's not about the CVE]
> [adding ext and Theodore to CC]
> 
> On mar., 2016-03-29 at 19:24 +0200, Hugues ANGUELKOV wrote:
>> Hello,
>> 
>> The linux kernel is prone to a Denial of service when mounting specially
>> crafted ext2/ext3 (possibly ext4) filesystems. This occurs in the function
>> ext4_handle_error who call the panic function on precise circumstance.
> 
> Did you contact the upstream maintainers about this? I'm adding them just in
> case they're not already aware of that…
> 
>> This was tested on severals linux kernel version: 3.10, 3.18, 3.19, on
>> real hardware and Xen DomU PV & HVM (the crash report attached is from a
>> Fedora 3.18 PV DomU), from different distribution release: Ubuntu, CentOS,
>> Fedora, Linux Mint, QubesOS.
>> This a low security impact bug, because generally only root can mount
>> image, however on Desktop (or possibly server?) system configured with
>> automount the bug is easily triggable (think of android smartphone? Haven't
>> test yet).

It seems that the important point here is that the filesystem has
"s_errors=EXT4_ERRORS_PANIC" set in the superblock?  I don't think
the actual corruption that triggered the ext4_error() call is important,
since there are any number of other failure cases that could generate
a similar error.

It seems practical to change s_errors at mount time from EXT4_ERRORS_PANIC
to EXT4_ERRORS_RO for filesystems mounted by regular users.  The question
is whether there is a way for the ext4 code to know this at mount time?

Cheers, Andreas

>> The crafted image may be burn onto SD card or USB key to crash a large
>> panel of linux box.
>> 
>> 
>> [ 929.200197] EXT4-fs error (device loop0): ext4_iget:4058: inode #2: comm
>> mount: bad extended attribute block 8390656
>> [ 929.200226] Kernel panic - not syncing: EXT4-fs (device loop0): panic
>> forced after error
>> [ 929.200226]
>> [ 929.200230] CPU: 1 PID: 980 Comm: mount Tainted: G O
>> 3.18.17-8.pvops.qubes.x86_64 #1
>> [ 929.200233] 0000000000000000 000000007533690c ffff88000ea07aa8
>> ffffffff81722191
>> [ 929.200237] 0000000000000000 ffffffff81a84108 ffff88000ea07b28
>> ffffffff8171a462
>> [ 929.200240] ffff880000000010 ffff88000ea07b38 ffff88000ea07ad8
>> 000000007533690c
>> [ 929.200244] Call Trace:
>> [ 929.200249] [<ffffffff81722191>] dump_stack+0x46/0x58
>> [ 929.200253] [<ffffffff8171a462>] panic+0xd0/0x204
>> [ 929.200257] [<ffffffff812ae4d6>] ext4_handle_error.part.188+0x96/0xa0
>> [ 929.200260] [<ffffffff812ae838>] __ext4_error_inode+0xa8/0x180
>> [ 929.200264] [<ffffffff81292869>] ext4_iget+0x929/0xae0
>> [ 929.200267] [<ffffffff812b31fb>] ext4_fill_super+0x18db/0x2b60
>> [ 929.200270] [<ffffffff8120af20>] mount_bdev+0x1b0/0x1f0
>> [ 929.200273] [<ffffffff812b1920>] ? ext4_calculate_overhead+0x3d0/0x3d0
>> [ 929.200276] [<ffffffff812a3425>] ext4_mount+0x15/0x20
>> [ 929.200278] [<ffffffff8120b879>] mount_fs+0x39/0x1b0
>> [ 929.200282] [<ffffffff811afd95>] ? __alloc_percpu+0x15/0x20
>> [ 929.200285] [<ffffffff8122754b>] vfs_kern_mount+0x6b/0x110
>> [ 929.200287] [<ffffffff8122a38c>] do_mount+0x22c/0xb60
>> [ 929.200290] [<ffffffff811aab96>] ? memdup_user+0x46/0x80
>> [ 929.200292] [<ffffffff8122b002>] SyS_mount+0xa2/0x110
>> [ 929.200295] [<ffffffff8172a609>] system_call_fastpath+0x12/0x17
>> [ 929.200301] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation
>> range: 0xffffffff80000000-0xffffffff9fffffff)c
>> 
>> I cannot attach the PoC (2x2MB too large) nor sending it in plain text
>> (they are filesystems), so I've uploaded it on this website of free file
>> sharing ... (sorry for the inconvenient):
>> poc.ext2 https://1fichier.com/?zbk2gohk8s
>> poc.ext3 https://1fichier.com/?9r0c8agjfa
>> 
>> Can you assign a CVE for this?
>> Thank for reading and your time.
>> 
>> Hugues ANGUELKOV.
>> 
>> 
> --
> Yves-Alexis
> 


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Theodore Ts'o]

On Tue, Mar 29, 2016 at 04:56:11PM -0600, Andreas Dilger wrote:
> On Mar 29, 2016, at 3:14 PM, Yves-Alexis Perez <corsac@debian.org> wrote:
> > 
> > [dropping MITRE from CC since it's not about the CVE]
> > [adding ext and Theodore to CC]
> > 
> > On mar., 2016-03-29 at 19:24 +0200, Hugues ANGUELKOV wrote:
> >> Hello,
> >> 
> >> The linux kernel is prone to a Denial of service when mounting specially
> >> crafted ext2/ext3 (possibly ext4) filesystems. This occurs in the function
> >> ext4_handle_error who call the panic function on precise circumstance.
> > 
> > Did you contact the upstream maintainers about this? I'm adding them just in
> > case they're not already aware of that…
> > 
> >> This was tested on severals linux kernel version: 3.10, 3.18, 3.19, on
> >> real hardware and Xen DomU PV & HVM (the crash report attached is from a
> >> Fedora 3.18 PV DomU), from different distribution release: Ubuntu, CentOS,
> >> Fedora, Linux Mint, QubesOS.
> >> This a low security impact bug, because generally only root can mount
> >> image, however on Desktop (or possibly server?) system configured with
> >> automount the bug is easily triggable (think of android smartphone? Haven't
> >> test yet).
> 
> It seems that the important point here is that the filesystem has
> "s_errors=EXT4_ERRORS_PANIC" set in the superblock?  I don't think
> the actual corruption that triggered the ext4_error() call is important,
> since there are any number of other failure cases that could generate
> a similar error.
> 
> It seems practical to change s_errors at mount time from EXT4_ERRORS_PANIC
> to EXT4_ERRORS_RO for filesystems mounted by regular users.  The question
> is whether there is a way for the ext4 code to know this at mount time?

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.

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.

You might as well complain that since the system ships with a reboot
command that can be executed by a clueless root user, that this is a
potential DOS attack scenario deserving of a CVE....

	      	     	      		   - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [oss-security] CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Eric Sandeen]

On 3/30/16 3:43 PM, Theodore Ts'o wrote:
> On Tue, Mar 29, 2016 at 04:56:11PM -0600, Andreas Dilger wrote:
>> On Mar 29, 2016, at 3:14 PM, Yves-Alexis Perez <corsac@debian.org> wrote:
>>>
>>> [dropping MITRE from CC since it's not about the CVE]
>>> [adding ext and Theodore to CC]
>>>
>>> On mar., 2016-03-29 at 19:24 +0200, Hugues ANGUELKOV wrote:
>>>> Hello,
>>>>
>>>> The linux kernel is prone to a Denial of service when mounting specially
>>>> crafted ext2/ext3 (possibly ext4) filesystems. This occurs in the function
>>>> ext4_handle_error who call the panic function on precise circumstance.
>>>
>>> Did you contact the upstream maintainers about this? I'm adding them just in
>>> case they're not already aware of that…
>>>
>>>> This was tested on severals linux kernel version: 3.10, 3.18, 3.19, on
>>>> real hardware and Xen DomU PV & HVM (the crash report attached is from a
>>>> Fedora 3.18 PV DomU), from different distribution release: Ubuntu, CentOS,
>>>> Fedora, Linux Mint, QubesOS.
>>>> This a low security impact bug, because generally only root can mount
>>>> image, however on Desktop (or possibly server?) system configured with
>>>> automount the bug is easily triggable (think of android smartphone? Haven't
>>>> test yet).
>>
>> It seems that the important point here is that the filesystem has
>> "s_errors=EXT4_ERRORS_PANIC" set in the superblock?  I don't think
>> the actual corruption that triggered the ext4_error() call is important,
>> since there are any number of other failure cases that could generate
>> a similar error.
>>
>> It seems practical to change s_errors at mount time from EXT4_ERRORS_PANIC
>> to EXT4_ERRORS_RO for filesystems mounted by regular users.  The question
>> is whether there is a way for the ext4 code to know this at mount time?
> 
> 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.
> 
> 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.
> 
> You might as well complain that since the system ships with a reboot
> command that can be executed by a clueless root user, that this is a
> potential DOS attack scenario deserving of a CVE....

First of all, yes, I have always been extremely skeptical of these
"crafted image" CVEs.  However, I'm not sure the "store errors=panic
in the superblock" was particularly well thought out either; it certainly
does make for a tidy little timebomb.

While I really hate to give issues such as this a whole lot more
credibility, I wonder about a higher level control, such as a sysctl,
which could [dis]allow errors=panic at a system-wide level.  It could default
to disallowing, and it's trivial to set it in sysctl.conf if you really
want it enabled by default.

In the end, errors=panic is really a debug option; a small hoop-jump to
use it doesn't sound too bad to me.

-Eric



--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Theodore Ts'o]

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

Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Kurt Seifried]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]

On Wed, Mar 30, 2016 at 2:43 PM, Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> 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).


>
> 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?"


>
>                                            - Ted
>



-- 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org

Re: CVE Request - Linux kernel (multiple versions) ext2/ext3 filesystem DoS

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

On Mar 31, 2016, at 8:53 AM, Kurt Seifried <kseifried-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> 
> 
> 
> On Wed, Mar 30, 2016 at 2:43 PM, Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> 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 #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]