SoylentNews is people
SoylentNews
from the just-when-you-think-you're-safe-from-Windows dept.
https://www.phoronix.com/news/NTFS3-Vulnerability-For-Root
A reported security vulnerability for the NTFS3 driver has gone unaddressed since being reported earlier this summer. The vulnerability allows a pre-crafted NTFS image on a USB flash drive or similar to allow the user to gain root access to the running Linux system.
After being reported privately two months ago and going unresolved, a SUID injection leading to local privilege escalation was made public. A Phoronix reader noted the disclosure via the NTFS3 mailing list.
Vova Tokarev who discovered the issue noted:
"A pre-crafted NTFS image (e.g. USB drive) with $LXUID=0, $LXGID=0, $LXMOD=0104755 already in the MFT produces a setuid-root binary the moment the volume is mounted. No setxattr() is involved -- the EAs are on disk. The -EPERM check doesn't help.
The root cause is still at fs/ntfs3/xattr.c:1022:
inode->i_mode = le32_to_cpu(value[2]);
This loads S_ISUID/S_ISGID directly from untrusted on-disk data. Desktop automounters (udisks) mount NTFS with suid by default, so plugging in a crafted USB gives any local user euid=0.
Suggested one-line fix:
- inode->i_mode = le32_to_cpu(value[2]);
+ inode->i_mode = le32_to_cpu(value[2]) & ~(S_ISUID | S_ISGID);I have a full PoC and working demo."
Those interested can find the proof of concept and demo along with more information via this mailing list post.
As of writing the vulnerability has yet to be addressed by the mainline NTFS3 kernel driver. This doesn't appear to impact the newer NTFS driver alternative that also continues maturing within the mainline kernel tree.
(Score: 5, Informative) by Bentonite on Friday August 28, @02:57AM
It's a case of someone over-reacting over nothing again.
It appears to apply to both ext4 and ntfs, as it seems the udisks automounter sets the suid flag by default (such flag means, yes, allow suid/sgid binaries on this storage medium).
The "root cause" part is the function that loads the xattr permissions from disk - so yes setxattr() was involved at some stage in the past.
The suggested patch is to seriously break suid/sgid functionality, which will break suid programs intentionally stored on ntfs partitions and he wonders why the patch is not accepted.
The only suggestion that would make sense, would be to make udisks default to not mounting ntfs with the suid flag by default anymore, to prevent microsoft from installing suid malware on ntfs partitions and hoping that someone accidentally runs it (realistically, sane people store suid programs on decent filesystems and insane people can set the suid flag).
It's well known that if a user has physical access and has control of a program with the root perms needed to add a filesystem with the suid flag, that user can get root via a suid binary (with physical access and if there are any unencrypted disks, you can just pull a disk, add a suid binary with another computer and put it back (or you can just change the root password if the rootfs is unencrypted)).