Cryptsetup Vulnerability Grants Root Shell Access On Some Linux Systems (threatpost.com) 89
msm1267 quotes a report from Threatpost: A vulnerability in cryptsetup, a utility used to set up encrypted filesystems on Linux distributions, could allow an attacker to retrieve a root rescue shell on some systems. From there, an attacker could have the ability to copy, modify, or destroy a hard disk, or use the network to exfiltrate data. Cryptsetup, a utility used to setup disk encryption based on the dm-crypt kernel module, is usually deployed in Debian and Ubuntu. Researchers warned late last week that if anyone uses the tool to encrypt system partitions for the operating systems, they're likely vulnerable. Two researchers, Hector Marco of the University of the West of Scotland and Ismael Ripoll, of the Polytechnic University of Valencia, in Spain, disclosed the vulnerability on Friday at DeepSec, a security conference held at the Imperial Riding School Renaissance Vienna Hotel in Austria. According to a post published to the Full Disclosure mailing list, the vulnerability (CVE-2016-4484) affects packages 2.1 and earlier. Systems that use Dracut, an infrastructure commonly deployed on Fedora in lieu of initramfs -- a simple RAM file system directory, are also vulnerable, according to the researchers. The pair say additional Linux distributions outside of Debian and Ubuntu may be vulnerable, they just haven't tested them yet. The report adds: "The problem stems from the incorrect handling of a password check when a partition is ciphered with LUKS, or Linux Unified Key Setup, a disk encryption specification that's standard for Linux. Assuming an attacker has access to the computer's console, when presented with the LUKS password prompt, they could exploit the vulnerability simply by pressing 'Enter' over and over again until a shell appears. The researchers say the exploit could take as few as 70 seconds. After a user exceeds the maximum number of three password tries, the boot sequence continues normally. Another script in the utility doesn't realize this, and drops a BusyBox shell. After carrying out the exploit, the attacker could obtain a root initramfs, or rescue shell. Since the shell can be executed in the initrd, or initial ram disk, environment, it can lead to a handful of scary outcomes, including elevation of privilege, information disclosure, or denial of service."
Linexit! (Score:4, Funny)
That does it, I'm moving to Windows 10!
-32768 Troll
Re: (Score:2)
You might want to monitor for outbound connections to alfabank.ru.
Re: (Score:2)
hmm... qemu VMs make the console available through the network. I am sure there is other possibilities...
Re: (Score:1)
If you're encrypting the rootfs, it's very likely to be a laptop or other system where access is normally from the local console. It's encrypted to secure it in the event it "grows legs".
My desktop workstation is fairly safe, sitting in an office I can lock, in an office suite that's always locked, in a building with limited access, etc. etc. The "engineering" laptop, however, is often outside that pseudo-secure environment. On more than one occasion, we've had laptops stolen out of hotel rooms, parked rent
Re:Linux sUKS -not! (Score:4, Insightful)
What's the difference between this "attack" and inserting a live CD?
Re: (Score:2)
The fact that BIOSes/UEFIs could be password protected and not allow other devices to boot.
This allows you to boot into a liveCD and do anything (like they said: spy on the network, brute force the key).
I would say this is not a major issue:
- for the servers, they are(should be) monitored and a few minutes of downtime will be noticed. But if somebody has physical access, security has other problems.
- for laptops or other PCs removed from secure environment, the issue is almost not a problem,
Re:This is the year (Score:5, Insightful)
While this news isn't great, the encrypted image remains encrypted. If you allow your computer to boot to anything other than your main secure and encrypted setup, then someone with physical access at boot that has made it to that point in the boot process could simply boot to a rescue disk (usb/cd/network/etc), and then do even more damage. Also, since they have physical access, they could just pop out the drive and mirror it via any other system, or reset the bios (to clear bios password) and allow boot by other media. And if you had a bios password, how did they get past that to get to the exploit step?
This isn't good, but it doesn't seem to be a big deal either.
Re: (Score:2)
Assuming an attacker has access to the computer's console
If the attacker has access to the system they have too much access.
Re: (Score:1)
Re: (Score:2)
This isn't good, but it doesn't seem to be a big deal either.
This isn't a big deal for the vast majority of Linux use-cases. Where something like this becomes a problem is kisok-like machines and certain "secure" environments.
For example, a certain US state's lottery machines, which run Linux. The machine has a list of USB device ID's it will accept, it's on a VPN, locked case, locked BIOS. All-in-all, pretty secure against tampering. However, the USB protection only goes so far because it's possible to craft a USB device which sends a fake ID.
That said, even if some
Re: (Score:1)
"TBH I am an avid linux fan for random projects or for scripting things that I would have to do by hand in windows (OMG I run Windows I must already by PWNED!)"
The M$ sockpuppets are strong today.
It will if you have a flash drive, same as ctrl-al (Score:4, Insightful)
> if you have physical access to the machine. But to be clear I don't think my Windows install will drop me to the desktop if I press enter on the password prompt for 70 seconds! LOL. Not to Linux bash
It'll give you a desktop if you put in a bootable flash drive first.
Btw the "issue" discussed here isn't a Linux bash shell either. It's an initrd nash. You're not logged into the OS, which is still securely encrypted.
Sure you could damage the data by reformatting the drive, but given you need physical access you could just as easily damage the drive with a hammer.
Re: (Score:2)
Or you could mount the filesystem that contains the program to unlock the disk and replace it with one that leaks the typed passphrase somewhere.
But yes, the same can be had using a bootable usb drive. Then again, there are network-accessible consoles...
Re: (Score:2)
Have you even read the comment you're replying to? If not:
you could mount the filesystem that contains the program to unlock the disk and replace it with one that leaks the typed passphrase somewhere.
If you think you could get around that issue by simply having the unlocking-program on the encrypted disk, then I might have a bridge to sell to you.
Re: (Score:2)
No, that's actually more difficult, since you'll have to pull the server out of the rack, open it, potentially power it down. More visible, too. If you can't program yourself out of a wet paper bag, maybe.
That said, I'd like to see you pulling that off over the network, too.
Re: (Score:2)
Re: (Score:2)
Does too, if the console is accessible over the network....
Re: (Score:2)
It counts as console access, but that does not mean physical access. If you don't understand this, think about how you would install a $5 hardware keylogger over a network-accessible system console. If you do understand this, then WTF is your point?
Re: (Score:3)
Re: (Score:2)
If you can touch it, you can own it (Score:5, Informative)
I was always taught that this pretty much means game over. It might be an interesting way to get a root shell, but if I am sitting in front of the machine with console access, I can think of a number of other ways to get a root shell.
Re:If you can touch it, you can own it (Score:5, Funny)
"If you can touch it, you can own it"
That's known as Trump's Postulate.
Re: (Score:2)
"If you can touch it, you can own it"
Which is of course not true if "own it" means "access data encrypted with a strong key and a non-trivial-to-brute-force password".
And of course this vulnerability gives you root access in the initramfs, but no access to any of the LUKS protected drives. At best, it's an easier way to perform an Evil Maid Attack, but we already knew that about whole disk encryption.
So really this is just about making it much more convenient to perform an attack that we already knew was feasible (feasible here means not somet
Re: (Score:2)
Which is of course not true if "own it" means "access data encrypted with a strong key and a non-trivial-to-brute-force password".
Not true. The kernel and initramfs itself need to be stored in cleartext (or else, how would the machine boot?). So, the exploiter would proceed as follows:
1. Use the vulnerability to get a root shell
2. Doctor a couple of scripts to log encryption password, or to inject a script into the root once encryption password has been entered.
3. Use cpio and bzip to build a new initramfs from the image in memory
4. Write that image to the appropriate part of the (cleartext) boot partition.
5. Log off, go away, an
Re: (Score:2)
Congratulations, you've just described the Evil Maid Attack that I linked from Schneier's blog post on Oct 23, 2009.
Re: (Score:2)
> I can think of a number of other ways to get a root shell
ok, i'll bite. how?
What is the Enter key supposed to do? (Score:3)
but seriously: the problem does not seem that serious at all: encrypted media are still encrypted and what you get is like a rescue shell. You can damage the encrypted media, but this is the case as soon as there is physical access to the machine. TFA says you can install a keylogger but if you have physical access you can plug in the logger between keyboard and usb even faster.
Re: (Score:1)
It may be a weird threat model, but it's always good to have the specifics on bugs that potentially affect security, even in corner cases.
Re: (Score:1)
I agree, it's not ZOMG CRITICAL but it's worth thinking about. The main issue is that sometimes that rescue shell is really, really useful. Just a few months ago I upgraded a Debian server to systemd and spent the better part of an hour trying to diagnose systemd failing to boot, switching back and forth between sysv (which booted just fine but I couldn't see the errors with journalctl) and systemd (which would spin forever on mounting /tmp and refused to give me any kind of rescue shell or way to cancel m
Re: (Score:3)
Re: (Score:1)
Distributions used to be put together by people scratching their own itches. Now, there are a bunch people paid to scratch around even when there are no itches; this results in oozing sores.
More quality RedHat code (Score:2)
RedHat took a turn for the worse about a decade ago and now we're reaping the rewards. I can't help but think there was a fundamental change in management that spurred mountains of code to come pouring out of RedHat.
Re: (Score:1)
Oh right.. crypto is hard. Bitching in a comment is not.
So what? Tested this on Fedora 25 (Score:5, Interesting)
How is dropping to initrd "root" access?
1. If you already have physical access to the console, all bets are off anyway. Security 101.
2. If you have WDE enabled, dropping to root gets you initrd only - no passwords, no privileges, nada - all it lets you do is try to mount the file system which can't be because it's encrypted. Only /boot should be unencrypted.
3. The only possible attack vector is to swap out the kernel image. But there are simpler ways to do that than run an exploit.
Did these guys watch too many episodes of the new MacGyver and consider themselves hackers instead of script kiddies?
Did they report the problem as only present if you encrypt specific volumes (which is stupid anyway because your passwords are visible now).
It takes a lot of effort to avoid WDE when installing linux these days. Only an idiot would misconfigure and render his system vulnerable like this. And only an idiot would give his keys to the castle to people he didn't trust.
Social Engineering wins every time and there is nothing you can do about it.
Re:So what? Tested this on Fedora 25 (Score:5, Insightful)
Indeed. You basically get the same as booting a rescue-system or removing the disk and accessing it directly gets you. In all, but a few very special set-ups, this means this is not actually a vulnerability or a bug that needs fixing. However, in these few very special set-ups, the standard distro-mechanisms are not enough to protect you anyways and if you rely on them, you have bigger problems than a root-shell with an unlocked encrypted root partition.
This is not worthy of a CVE. My guess is some big egos with rather small skills are at work here.
Re: (Score:1)
Use loop-aes... (Score:2)
Re: (Score:1)
Re: (Score:2)
And fail. This is not a LUKS vulnerability. This is a vulnerability of the boot-script added by the distribution. Loop-AES will have exactly the same (mostly non-issue) with this script.
Re: (Score:2)
Indeed. And if you roll your own initramfs, which is not difficult with some grasp of UNIX shell-scripting, you can have exactly the failure-behavior you want. 100 lines of code is already a long one. Of course, there are now a lot of Windows refugees and they often cannot do any shell-scripting at all and are dependent on the distro-scripts being secure. But such people have no business administrating a security-critical Linux system anyways.
It's not vulnerability in cryptsetup! (Score:1)
How to mark article as _TOTAL LIE_ ? It's not vulnerability in cryptsetup! Only in some Linux distribution stupid shell scripts that execute cryptsetup.
initramfs, not cryptsetup (Score:1)
It has been said, but the vulnerability is not in cryptsetup, but in initramfs.
Total encryption (Score:2)
I tried this on one of my systems, and indeed, it dropped me to a root busybox shell in initrd. Since my grub is not password protected, this kind of access (and worse) was already trivial on that system. But, LUKS is still encrypted.
Nowadays grub supports what I call total encryption. (It has support for a LUKS encrypted partition, no need for a separate unencrypted /boot directory.) Now a similar vulnerability was present on one of my total-encrypted systems, but in this case it dropped me to a grub rescu