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.
What will he do???
Thank God I don't use a root password, or encrypt anything. Just hit enter and get a root prompt. Nothing to exploit, so I'm safe!
yes.
Remember this is the year of linux.
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!)
I don't know if Bitlocker is totally secure, but I doubt anything is actually secure 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, and it's great that you're able to debug these issues since they are open source but let's not pretend that open-source = perfect OS for everything which seems to be the standard here.
As a side note I am sure the NSA is very sad right now but I am sure they are busy looking for another backdoor. Though I think this attack should probably just be considered crawling through the doggy door.
In other words... Not a problem from the internet.
The attacker has physical access to a full-disk encrypted system but doesn't know the password. They press ENTER a few hundred times and the init system drops them to a recovery shell that has the same level of access that they'd have if they just removed the disk and inserted it in a machine they do control. They're only going to get encrypted data, or the same data they could have obtained by removing the disk.
The only part that might be remotely concerning is the attacker now has root on a booted machine and can maybe bypass BIOS boot security by forcing the kernel to run untrusted exploit code instead of booting it. That's not something you can accomplish easily by removing the disk and replacing the kernel if secure boot is enabled.
I can see this being an issue if the user has remote console access (ILO, etc), but that's almost as good as physical access anyway.
This doesn't seem like much of a risk.
Full disk encryption only protects your data.
Full disk encryption doesn't and can't protect the machine from someone who has physical access to your machine. Nothing really can.
If someone has physical access to your machine they could: Install a hardware keylogger like this https://www.amazon.com/dp/B004TUBOKW
Install malicious firmware (replace/extended the system EFI)
Install a malicious bootload (e.g. a hacked GRUB (since grub isn't and can't be protected by the full disk encryption)).
Full disk encryption is good, and should be used, but its users should understand, it only protects your data from theft, if your machine is powered off at the time of theft. If you machine is powered on and the decryption password has already been entered... then, well see this: http://www.businessinsider.com/ross-ulbricht-will-be-sentenced-soon--heres-how-he-was-arrested-2015-5
You machine can only be trusted if no one else has tampered with it.
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.
why bother physical access gives all kinds of posibilities. this is copy delete etc not access persay. how about take the drives how about clone the disks sure but there encrypted thats the purpose to protect the data on them. being able to delete and copy would suck(unless you have backups though inconvienent) its still protected the data from others. physical access could give a chance for keylogger even physical or perhaps firmware like bios level.
didnt hear anything about cracked.
Leading Linux distributions (Ubuntu, Red Hat, even Debian) and their derivatives is that they look more and more like Windows with each new release. Even their defects are more and more reminiscent of those in Windows.
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.
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.
I use LUKS on my Debian laptop. I can get an initramfs shell in many different ways, one of them by simply rebooting the laptop and choosing the appropiate boot option.
Another way that works on my server which has the boot partition in a USB inside the case is by simply unplugging one of the hard drives.
I agree that is better to close this hole but it is not alarming bug. The heading is a little bit scary.
> 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.
If you can't touch it, it can't fuck you via APK Hosts File Engine 9.0++ SR-4 32/64-bit https://www.google.com/search?...
Ads rob speed, security (malvertising) & privacy (tracking).
Hosts add speed (hardcodes/adblocks), security (bad sites/poisoned dns), reliability (dns down), & anonymity (dns requestlogs/trackers) natively.
Works vs. caps & PUSH ads.
Avg. page = big as Doom http://www.theregister.co.uk/2... & ads = 40% of it.
Hosts != ClarityRay blockable (vs. souled-out to admen inferior wasteful redundant slow usermode addons)
Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus (slows you) + less security issues/complexity.
Compliments firewalls (blocking less used IP addys vs. hosts blocking more used domains) & DNS (lightens dns load).
Gets data via 10 security sites.
APK
P.S. - Safe https://www.virustotal.com/en/... (Verified by Malwarebytes' S. Burn "seen the code & it's safe" http://forum.hosts-file.net/vi... )
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.
Only seemed secure because no one was trying to get into it.
there are network-accessible consoles...
Hector Marco & Ismael Ripoll claim this exploit will work in cloud environments - but it seems to rely on an encrypted initramfs and an unencrypted /
In other news GRUB gives me a command line, LUKS can be loosely configured with various encryption options.
All that speculation aside - I'm still waiting for the exploit authors to respond to the request that they explain what version they base the exploit (claim) on.
On Mon, Nov 14, 2016 at 08:45:51PM +0000, Hector Marco wrote:
Hello All,
Affected package Cryptsetup = 2:1
Hi,
Can you clarify which versions are affected?
The latest upstream version is 1.7.3:
https://gitlab.com/cryptsetup/cryptsetup/commits/master
What is the 2:1 version?
(Re: [FD] [oss-security] CVE-2016-4484: - Cryptsetup Initrd root Shell fulldisclosure@seclists.org 15/11/16 14:27)
...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?
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!
Yeah, fix it. Annoying.
That said, the primary threat model LUKS is protecting me from is someone stealing my laptop and getting at potentially sensitive data.
Those already own everything, can wipe the disk and *can replace the boot loader and the initramfs, since those are unencrypted* (that's basically the stupidly called "evil chambermaid attack": install a boot kit that lets me think I'm entering my LUKS passphrase while it posts it to twitter or what).
IOW: this bug doesn't make things worse than they are know to be[1]. Still it's a bug and merits fixing.
[1] Unless you're into "Secured Boot" and "Trusted Foo". But then you gotta convince me that you kinda understand what all that is about.
CD's are easy to stop (e.g. remove the drive).
A much bigger problem is hardware keyloggers (just insert between keyboard and USB slot), Firewire DMA access, etc.
That's assuming you have an up to date backup, of course, which in most cases means being part of an enterprise environment where saving data on the local drive is a firing offense anyway. Otherwise, no encryption is going to stop the bad guy for erasing all your important stuff with a hammer or cattle prod.
Using a $5 hardware keylogger would be easier.
How to mark article as _TOTAL LIE_ ? It's not vulnerability in cryptsetup! Only in some Linux distribution stupid shell scripts that execute cryptsetup.
What's one of those?
When calling someone out, better make sure your post is 100%.
I'd say you were more of a Grammar Nazi wannabe.
Yeah. Exploiter is now 'root' on a machine with fs only resides on RAM.
What's his next destination? Probably no where...
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!
As of today, latest version of cryptsetup is 1.7.3
https://gitlab.com/cryptsetup/cryptsetup
And yet the article says the issue affects versions 2.1 and earlier .. ?! does the author of the article has the ability to read the future?
Have you heard of USB DVD drives? They are all the rage with the kids.
That still counts as local access.
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!