[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
On Mar 29, 2016, at 3:14 PM, Yves-Alexis Perez <[email protected]> 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
On Tue, Mar 29, 2016 at 04:56:11PM -0600, Andreas Dilger wrote:
> On Mar 29, 2016, at 3:14 PM, Yves-Alexis Perez <[email protected]> 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
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 <[email protected]> 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