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, Insightful) by looorg on Thursday August 27, @05:47PM (1 child)
So physical access to the machine to insert a USB drive. Right. This has been around for eons. But it used to be on Windows machines. With a pre-crafted Linux floppy image (later a CD image, then a USB image) that would boot in and manipulate the user account database on Windows to give you access. It was also a great way to reset the admin account if you "forgot" the password. It wasn't particularly stealthy tho as it made changes and not just told you the password. So other people that wanted to login couldn't. Cause you changed the password.
https://pogostick.net/~pnh/ntpasswd/bootdisk.html [pogostick.net]
(Score: 5, Informative) by PhilSalkie on Thursday August 27, @06:17PM
No _Personal_ physical access needed - but lots of people get handed USB sticks and put them in their computer - heck, lots of people _buy_ USB sticks and put them in their computer.
This method is _exactly_ how the Stuxnet worm was introduced to the Natanz nuclear site in Iran - they loaded the worm onto a bunch of USB sticks and fed them into the supply chain so they wound up in the local market stalls. It just took somebody buying one and putting in their Windows computer, the rest was history.
In this case, the stick just needs to have an ELF file that's called "image.jpg" or "Recycle Bin" or something else that gets an unwary user to click on it, and now there's a rootkit on the machine. Even easier if there's some auto-run setup that's available (or a vulnerability that lets something trigger, like naming the ELF as "picture.jpg" so it gets scanned for a thumbnail, and that scanning of the file allows a vuln to get exploited to get the ELF file run - can be a lower harm level of vuln, the ELF is already SUID root.)
(Score: 2, Insightful) by Anonymous Coward on Thursday August 27, @10:52PM (1 child)
> produces a setuid-root binary the moment the volume is mounted.
So... what if someone creates an ext4-formatted USB key, and creates a root-owned SUID executable file on it? Does that USB key cause the same "bug" as this discusses?
From the summary and the e-mail, it seems that's what's happening. Just, NTFS vs ext4. Is NTFS simply not allowed to have SUID files on its filesystem, according to driver expectations?
Does `udisks` not auto-mount ext4 filesystems on USB keys?
What's the issue here? someone over-reacting about nothing, again? It's not like this is Windows and autorun.inf.
(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)).