Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Security Communications Debian Encryption Network Networking Open Source Operating Systems Ubuntu Linux

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."
This discussion has been archived. No new comments can be posted.

Cryptsetup Vulnerability Grants Root Shell Access On Some Linux Systems

Comments Filter:
  • Linexit! (Score:4, Funny)

    by Tablizer ( 95088 ) on Tuesday November 15, 2016 @06:23PM (#53292685) Journal

    That does it, I'm moving to Windows 10!

    -32768 Troll

  • by C3ntaur ( 642283 ) <centaur AT netmagic DOT net> on Tuesday November 15, 2016 @06:37PM (#53292797) Journal
    "Assuming an attacker has access to the computer's console"

    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.

    • > I can think of a number of other ways to get a root shell

      ok, i'll bite. how?

  • by daniel23 ( 605413 ) on Tuesday November 15, 2016 @06:37PM (#53292805)

    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.

    • by Anonymous Coward

      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.

      • by Anonymous Coward

        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

    • You could probably build a new initramfs and install a key logger there to capture the encryption password. But if you have console access to the machine while it's booting you could probably do that anyway by removing and reinstalling the boot disk.
  • 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.

    • by wbr1 ( 2538558 )
      Put your skills where your mouth is and fix it or write new. This is open source after all.

      Oh right.. crypto is hard. Bitching in a comment is not.

  • by passionplay ( 607862 ) on Tuesday November 15, 2016 @07:18PM (#53293015)

    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.

    • by gweihir ( 88907 ) on Wednesday November 16, 2016 @04:19AM (#53295035)

      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.

  • ...and breath easy at night. Design of encryption systems should be done by experts.
    • Yup - the same security experts that gave the backdoor to the spy agencies. Yup!
    • by gweihir ( 88907 )

      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.

  • How to mark article as _TOTAL LIE_ ? It's not vulnerability in cryptsetup! Only in some Linux distribution stupid shell scripts that execute cryptsetup.

  • 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 rescu

"Indecision is the basis of flexibility" -- button at a Science Fiction convention.

Working...