Bug 1560782 (CVE-2018-1093) - CVE-2018-1093 kernel: Out of bounds read in ext4/balloc.c:ext4_valid_block_bitmap() causes crash with crafted ext4 image
Summary: CVE-2018-1093 kernel: Out of bounds read in ext4/balloc.c:ext4_valid_block_bi...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2018-1093
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20180322,reported=2...
Depends On: 1560784 1560785
Blocks: 1560786
TreeView+ depends on / blocked
 
Reported: 2018-03-27 00:59 UTC by Sam Fowler
Modified: 2019-06-08 22:47 UTC (History)
49 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
The Linux kernel is vulnerable to an out-of-bounds read in ext4/balloc.c:ext4_valid_block_bitmap() function. An attacker could trick a legitimate user or a privileged attacker could exploit this by mounting a crafted ext4 image to cause a crash.
Clone Of:
Environment:
Last Closed: 2018-04-07 09:37:43 UTC


Attachments (Terms of Use)

Description Sam Fowler 2018-03-27 00:59:14 UTC
The Linux kernel is vulnerable to an out-of-bounds read in ext4/balloc.c:ext4_valid_block_bitmap() function. An attacker could trick a legitimate user or a privileged attacker could exploit this by mounting a crafted ext4 image to cause a crash.

References:

https://bugzilla.kernel.org/show_bug.cgi?id=199181

http://seclists.org/oss-sec/2018/q1/284

An upstream patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7dac4a1726a9c

Comment 1 Sam Fowler 2018-03-27 00:59:46 UTC
Acknowledgments:

Name: Wen Xu

Comment 2 Sam Fowler 2018-03-27 01:00:39 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1560784]

Comment 6 Wen Xu 2018-04-05 19:28:38 UTC
(In reply to Vladis Dronov from comment #5)
> Notes:
> 
> While the reproducer works when run as a privileged user (the "root"), this
> requires a mount of a certain filesystem image. An unprivileged attacker
> cannot do this even from a user+mount namespace:
> 
> $ unshare -U -r -m
> # mount -t ext4 fs.img mnt/
> mount: mnt/: mount failed: Operation not permitted.
> 
> The article https://lwn.net/Articles/652468/ (thanks, Jonathan!) discusses
> unprivileged user mounts and hostile filesystem images:
>  
> > ... for the most part, the mount() system call is denied to processes running
> > within user namespaces, even if they are privileged in their namespaces.
> 
> It also states that unprivileged filesystem mounts are not allowed as of now
> in the Linux kernel and probably won't be allowed in a future:
> 
> > There were no proposals for solutions to the hostile-filesystem problem.
> > But, in the absence of some sort of assurance that they can be made safe,
> > unprivileged filesystem mounts are unlikely to gain acceptance; even if the
> > feature gets into the kernel, distributions would be likely to disable it.
> 
> So for now we hardly consider bugs which require mounting a filesystem image
> to exploit as security flaws.

Hi Vladis, I have a concern about your comment. Considering this issue, 
https://bugzilla.redhat.com/show_bug.cgi?id=1395190

With physical access to the computer, the attacker still can leverage automatic mount function of USB-device to exploit such kind of bugs?

Comment 7 Vladis Dronov 2018-04-07 08:59:13 UTC
(In reply to Wen Xu from comment #6)
> Hi Vladis, I have a concern about your comment. Considering this issue, 
> https://bugzilla.redhat.com/show_bug.cgi?id=1395190
> 
> With physical access to the computer, the attacker still can leverage
> automatic mount function of USB-device to exploit such kind of bugs?

Hello, Wen,

After an internal discussion this was reconsidered, please, see Notes below.

Comment 8 Vladis Dronov 2018-04-07 09:00:34 UTC
Notes:

While the reproducer works when run as a privileged user (the "root"), this requires a mount of a certain filesystem image. An unprivileged attacker cannot do this even from a user+mount namespace:

$ unshare -U -r -m
# mount -t ext4 fs.img mnt/
mount: mnt/: mount failed: Operation not permitted.

The article https://lwn.net/Articles/652468/ (thanks, Jonathan!) discusses unprivileged user mounts and hostile filesystem images:
 
> ... for the most part, the mount() system call is denied to processes running
> within user namespaces, even if they are privileged in their namespaces.

It also states that unprivileged filesystem mounts are not allowed as of now in the Linux kernel and probably won't be allowed in a future. Until that such flaws are considered as not exploitable:

> There were no proposals for solutions to the hostile-filesystem problem.
> But, in the absence of some sort of assurance that they can be made safe,
> unprivileged filesystem mounts are unlikely to gain acceptance; even if the
> feature gets into the kernel, distributions would be likely to disable it.

On the other hand, there is a potential possibility that still an attacker can trick a regular user to mount a malicious filesystem image, like trick him to insert an usb-flash-drive with a forged filesystem to a desktop system which will auto-mount it. In case this results only in a system crash (a DoS due to, for example, a NULL pointer dereference) the flaw impact is low but it still exists.

Another example is that if an attacker wants to hack into his coworker's notebook. While a coworker is away (on a coffee break) an attacker may insert an usb-flash-drive into the target notebook. In case of a flaw which results in a privilege escalation the flaw's impact is high. In case of a system crashes the impact is lower, but still a harm is done by crashing the system mid-work and losing a work done so far.

So the Red Hat would still consider bugs which require mounting a filesystem image to exploit as security flaws.

Comment 9 Vladis Dronov 2018-04-07 09:37:43 UTC
Notes:

While the above note is true in general, RHEL products are not affected by this exact bug.

Comment 10 Eric Sandeen 2018-04-10 04:26:13 UTC
(In reply to Vladis Dronov from comment #8)

> Another example is that if an attacker wants to hack into his coworker's
> notebook. While a coworker is away (on a coffee break) an attacker may
> insert an usb-flash-drive into the target notebook. In case of a flaw which
> results in a privilege escalation the flaw's impact is high. In case of a
> system crashes the impact is lower, but still a harm is done by crashing the
> system mid-work and losing a work done so far.

A malicious attacker could also simply pour their coffee into their co-worker's laptop if "loss of work done so far" was the attacker's desired outcome.

Let's please think very carefully about whether these "crafted images crash the system" bugs which require physical access to the machine to exploit truly constitute security issues.

Comment 11 Vladis Dronov 2018-04-17 16:31:12 UTC
(In reply to Eric Sandeen from comment #10)
> Let's please think very carefully about whether these "crafted images crash
> the system" bugs which require physical access to the machine to exploit
> truly constitute security issues.

In case of a flaw which results in a privilege escalation the flaw's impact is high. Yes, this exact case is not a privilege escalation, but some other can be.

Comment 12 Justin M. Forbes 2018-05-04 16:33:10 UTC
This is fixed for Fedora with 4.16.7 stable updates.


Note You need to log in before you can comment on or make changes to this bug.