Slashdot Mirror
Cryptsetup Vulnerability Grants Root Shell Access On Some Linux Systems (threatpost.com)
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."
That does it, I'm moving to Windows 10!
-32768 Troll
Table-ized A.I.
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.
Loading...
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.
605413? Yes, it's a prime.
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.
"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.
You might want to monitor for outbound connections to alfabank.ru.
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
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.
Assuming an attacker has access to the computer's console
If the attacker has access to the system they have too much access.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
Anons need not reply. Questions end with a question mark.
Which means that if an attacker can secretly gain physical access to a (non-libreboot) machine and modify the BIOS, then someone else later running tails on that machine could be compromised by this exploit? Is this correct?
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.
If we learned anything from Terminator Genisys, it was that.
> 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.
hmm... qemu VMs make the console available through the network. I am sure there is other possibilities...
Everything I write is lies, read between the lines.
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...
CLI paste? paste.pr0.tips!
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 rental cars, and once out of the office. (they hit every office in the building, btw. That laptop did find its way back to us, eventually.) Of course, we don't rely on hokey userland protections; we enable the laptop's own "TPM" (hardware) security measures and the hard drive's native full disk encryption.
Exactly. The thing is encrypted. You can boot it various ways, but without the password, it remains encrypted.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
...and breath easy at night. Design of encryption systems should be done by experts.
What's the difference between this "attack" and inserting a live CD?
It is secure - everything you can do anything in initrd using this exploit was already available as a feature w/o the exploit. Initrd has no passwords and no content. Until you enter the password for cryptsetup, you get access to nothign. And sure you have root access to INITRD but not the actual filesystem other than boot - but that was unfettered to start with.
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, as an attacker could already remove the HDD/SSD and clone it. Accessing network is not a problem.
The only vulnerable point would be if TPM-backed FDE is layered beneath LUKS OS encryption. But I doubt those who use LUKS trust TPM.
So again, a small vulerability is blown-out of proportions because it's hard to find GNU/Linux bugs/exploits.
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.
CLI paste? paste.pr0.tips!
How to mark article as _TOTAL LIE_ ? It's not vulnerability in cryptsetup! Only in some Linux distribution stupid shell scripts that execute cryptsetup.
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 someone could plug a keyboard into such a machine very little can be done because of the BIOS and bootloader password protection. However, a bug like this would suddenly be a potentially huge problem.
I'm tired of people making bugs like this sound like earth shattering problems. At the same time there are a minority of situations where this type of thing is potentially a big issue. That said, we can't ignore stuff like this.
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.
CLI paste? paste.pr0.tips!
But this attack doesn't work over the network in the first place....
Does too, if the console is accessible over the network....
CLI paste? paste.pr0.tips!
It has been said, but the vulnerability is not in cryptsetup, but in initramfs.
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 rescue environment.
I would be interested to hear what the possibilities are for evil maid attacts in the grub rescue shell scenario, but I don't believe it's possible, because the kernel and the initrd are still encrypted.
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?
CLI paste? paste.pr0.tips!