Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1597843 - (CVE-2018-12931) CVE-2018-12931 kernel: stack-based out-of-bounds write in ntfs_attr_find in the ntfs.ko
CVE-2018-12931 kernel: stack-based out-of-bounds write in ntfs_attr_find in t...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20180412,reported=2...
: Security
Depends On: 1597845 1600466 1597844
Blocks: 1597833
  Show dependency treegraph
 
Reported: 2018-07-03 13:05 EDT by Laura Pardo
Modified: 2018-08-28 18:50 EDT (History)
45 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in ntfs_attr_find in the ntfs.ko filesystem driver in the Linux kernel. This allows attackers to trigger a stack-based out-of-bounds write and cause a denial of service or possibly have unspecified other impact via a crafted ntfs filesystem image. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Laura Pardo 2018-07-03 13:05:34 EDT
A flaw was found in ntfs_attr_find in the ntfs.ko filesystem driver in the Linux kernel. This allows attackers to trigger a stack-based out-of-bounds write and cause a denial of service or possibly have unspecified other impact via a crafted ntfs filesystem image. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely.

References:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1763403
 	
https://marc.info/?l=linux-ntfs-dev&m=152413769810234&w=2

https://marc.info/?t=152407734400002&r=1&w=2 (a whole thread)
Comment 1 Laura Pardo 2018-07-03 13:06:38 EDT
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1597845]
Comment 7 Vladis Dronov 2018-07-12 08:13:51 EDT
Notes:

The NTFS filesystem is shipped only with Red Hat MRG-2 product.

While the flaw 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 ntfs 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. In case of a flaw which results in a privilege escalation the flaw's impact is higher.

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

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