Missing item in the series?
"Debian, Fedora and are confirmed as suffering from this problem." We breathlessly await the Linux distribution that should be following "and".
Attackers with a little more than a minute to spare can get their foot in the door on Linux boxes by holding down the Enter key for 70 seconds – an act that gifts them a root initramfs shell. The simple exploit, which requires physical access to the system, exists due to a bug in the Linux Unified Key Setup (LUKS) used in …
The the most notable missing item is a link to the actual report, which states:
Obviously, the system partition is encrypted and it is not possible to decrypt it (AFAWK). But other partitions may be not (sic) encrypted, and so accessible.
Right, so ... just like booting from a thumbdrive, and you still have no access to the encrypted filesystem.
Sorry, I must have missed the part where this is a "vulnerability", somehow.
Same goes for planting malware on the boot partition, you could do that by booting from a thumbdrive, then mount any unencrypted partition from there.
The "vulnerability" here, if there is one, is anything that isn't encrypted, not the fact that you can get shell access.
Oh and yes, it certainly is possible to encrypt the boot partition.
If you have root and while you don't have access to the encrypted partitions... there's still some dangerous stuff you can do. ... (And no, I won't even hint at it...) [Even with a machine that has an encrypted boot partition...]
But to your point... its not *that* dangerous.
First it requires physical access to the machine. Most linux servers are in a rack in a secured machine room. Second, you'd have to bring your own monitor and keyboard. So the odds are that if you already have physical access to the machine, you would already have root privileges.
This post has been deleted by its author
It's like you people are willfully missing the point.
At a kiosk machine/library machine etc you can't pull the disk out because it's completely fucking obvious to anyone nearby that you've just unscrewed the top of the box and are in the process of stealing some hardware.
You can't boot from a disk as they've (hopefully) locked that down/removed the dvd drive.
With this vulnerability you can hold down the enter key and get a root shell, to any casual observer you are just using the machine as normal, whilst the reality is your up to nefarious shenanigans that you shouldn't be.
"Clone the harddrive"... yes, by using the unexpected root shell that you've got to from this vulnerability.
"Clone the harddrive"... yes, by using the unexpected root shell that you've got to from this vulnerability.
Yeah, but, keeping with the "kiosk machine/library machine while not wearing a blue nylon jacket with 'FBI maintenance' printed on the back"...
1) Where do you plug in that additional drive?
2) Why would you want to clone the fricking harddrive in the first place?
Ok, so there should be screen that demands root password after you have not managed to type in the LUKS password correctly etc. etc.
But really.
I have a bigger issue with the screen lock on KDE Fedora 24 which shows the actual screen for about 1/10 of a second after a series of bad password entries...
If you have root and while you don't have access to the encrypted partitions... there's still some dangerous stuff you can do
Given the breach requires physical access I could:
1. Steal the drives and/or machine
2. Use a lump hammer on it
...
you get the idea.
Is there something more dangerous you can do from a busybox shell on the boot partition, than a full Linux system on a thumbdrive?
My point is that this "vulnerability" is not new, it has absolutely nothing to do with escaping the init script, and it certainly doesn't warrant a CVE report, unless the reporter is claiming to have only just discovered that unencrypted filesystems are (shock!) vulnerable to direct access, where the init shell is only one point of access, and not even the most useful, from a hacker's perspective.
Yeah, I'm not sure I'd describe this as a 'vulnerability' at all. Storage device encryption is not supposed to prevent people accessing a rescue shell on the system the encrypted storage device happens to be sitting in at that point in time. It's intended to prevent people accessing the *data on the encrypted device*. This 'attack' does nothing particularly significant to help you with that, except perhaps make it a bit easier to try a brute force attack.
Even if you do consider this a 'vulnerability', the authors of the article are *massively* overplaying it.
After vigorous "research" I have been able to trace this bug back to Thompson & Richie Unix.
WERE THEY SECRETLY WORKING FOR THE NSA ALL ALONG? WHAT DID RUBY ACTUALLY KNOW AND WHY IS OSWALD EVEN BEING MENTIONED IN THIS POST?
Shocking deathbed testimony from a hacker dying of a mysterious cancer he obtained from a fishy sushi in an unnamed London restaurant rips the veil off the long-running UNIX conspiracy!!
(After this message)
This is not a "find a linux box, press enter and access everything" kind of exploit.
Said root shell is the emergency shell launched after 93 failed attempts to decrypt the filesystems and continue booting.
It requires a linux system with encrypted boot filesystems you have terminal (not ssh) access to after a forced reboot of said system (powerfail, usually).
As we specifically talk about systems which will never restart on their own due to the password neccessary finding one of your systems crashed for whatever reasons now requires extra-extra caution as you may well find a keylogger or trojan present.
quick fix: adding panic=5 to your grub config.
good fix: as per CVE-2016-4484 (effectively stop offering the rescue shell and enter a boot loop).
hth
Quite. This article is severely lacking in several key details.
"With access to the shell, an attacker could then decrypt Linux machines". The implications are that this decryption would be easy. The reality is that you'd have access to a root shell, with an encrypted hard disk. How useful this is depends on the specific environment, but at least for me personally: as long as the "hackers" can't access any of my personal info on my hard drive, this is no worse than them bringing their own laptop and plugging it into the right sockets (with the MAC address of the network card spoofed). If the network is hardened correctly, then it's No Big Deal.
Gaining access to an environment where you can't actually see or do anything is arguably not really useful at all.
s/Windows/Just about any commercial enterprise-class OS too/
AIX, Solaris, HP-UX - If you have physical access (or access via the management interface), you can compromise the system.
Various attempts have been made to close or narrow this (tiny) loophole*, e.g.
- HP-UX Secure Boot wouldn't let you interrupt the boot; Unless you disconnected the boot disk and reset that option in the "BIOS" equivalent.
- Solaris wouldn't let you enter single-user mode without a password. Unless you booted from media.
*My knowledge may be out of date - disk encryption offers some interesting possibilities - but I'd bet that every boot security measure put in place has a backdoor. Writing off a production system just because someone lost the root password isn't an option for most organisations.
PS Vote thumbs down if you have a pony tail!
Dude! How are you bell bottom trousers? Got a boombox to go with it?
The last ponytail I saw was attached to a very aged guy re-entering computer science at uni and desperately trying to navigate the Macintosh 1. That was in 1990.
Obviously my category of "very aged" has changed since.
...my good impressions of El Reg as a tech-savvy pub.
This attack does *not* give you anything you could not get by using a USB boot, CD boot, or PXE (network) boot.
The only situation where you *do* get more than that is in "kiosk" type situations (where the CPU/case/disks are locked away but the keyboard/mouse/monitor are accessible).
And even then, the statement "With access to the shell, an attacker could then decrypt Linux machines" is totally wrong.
>And even then, the statement "With access to the shell, an attacker could then decrypt Linux machines" is totally wrong.
Not quite totally wrong. It just needs to be modified to
"With access to the shell, AND THE PASSWORD, an attacker could then decrypt Linux machines"
Some people just don't understand how disk encryption systems work.
With 'whole disk encrypttion' the /boot partition has to be unencrypted, otherwise the machine cannot boot - duh.
You can boot a computer up various ways and get a console - another duh.
The rest of the disk is still encrypted and the data is still unreadable and safe. So there is no problem, this is how it is supposed to work.
jake linked to this article http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
As it points out in the section marked Impact there may be other unencrypted partitions attached to the system, the hacker could compromise the boot partition for later exploitation, the encrypted disk could be copied for brute forcing at a later date or the attacker could just blat the encrypted disk.
As it points out in the section marked Impact there may be other unencrypted partitions attached to the system, the hacker could compromise the boot partition for later exploitation, the encrypted disk could be copied for brute forcing at a later date or the attacker could just blat the encrypted disk.
If the attacker has physical access to the system, why the fuck am I more worried about whether he could just blat the disk than the fact that the asshole has physical access?!?!
Anyone who falls to this bug likely has WAY bigger issues than whether someone can wipe an encrypted partition.
Actually it is possible to boot the whole encryption way..
There is an option in /etc/default/grub called GRUB_ENABLE_CRYPTODISK which should be set on for it work. Then GRUB will ask for your password to access the boot partition to load the config file and stuff.
The only drawback is that you have type the password two times, once in grub and second while the initramfs is mounted.
Tested full disk encryption on archlinux, works perfectly.
* This just gives you access to the initramfs shell, it does not actually give you access to the encrypted partition. The best they can do is bruteforce your password for access but as long as you have a decent password, it won't work or use some basic tools built into it.
* This does not work if the boot partition is encrypted or does not exist, thus being in the root partition itself happens to be in the encrypted partition. Technically having initramfs inside the partition will still render this bug useless.
* There's nothing wrong with the actual encryption, just some small error in a config file.
Why are news sites making a big deal over this?
Well, no it's not a myth. I'm not even sure this is a bug. You can log in in single user mode in most distributions, that's why they offer drive encryption. The attacker that has physical access still can't do anything (as in, can't grab files) if the drive is encrypted. The attacker can do harm to the installation, but that's it. Everything else is still secure. The attacker has physical access and might as well grab the drive and attach it to a USB to SATA converter. Does pretty much the same thing.
No. One cannot only wonder, but one can look into the source, too. That's still the point of open source.
Windows users should be scared by the amount of bugs that are being found every day in open source. Not because these are bugs, but because bugs are a part of all software developments. Just like people have their flaws so does software, and the more complex the software is the higher this number gets. It's a fact they need to open their eyes to.
To believe Windows and closed source to be secure in comparison to open source is naive - about as naive as closing your eyes and to believe the world and its flaws has suddenly disappeared.
Really, the only *issue* here is that they can copy the encrypted volumes or *possibly* install a keylogger. In any case, one has to have one's hands on the hardware (or VM control surface), and one has to have a tailored piece of software to install on the machine. -> at this stage one would be installing a kernel module to shanghai the keyboard input, thus "tailored".
Many distro's are getting into the habit of *not* mounting /boot during runtime unless called for (updating the kernel, rebuilding initramfs or initrd) to avoid having stuff dropped in there that does not belong due to drive by or 'stupid user issues'.
Systems on the DC floor? If you've made it to the console level or have your hands on the hardware, the game is already over.
Not so much a "massive security bug" as it is an "oh, crap, forgot to take that line I put in just in case out".
So it's 70 seconds, regardless of the key-depressed-repeat-rate and the key-depressed-repeat-delay?
Standing back, this looks like another way to say buffer overrun. I'm not even sure why that was ever a thing. It's like you dimension an array to 100, but if a process contrives to ask for record 110, it's not a computer room anymore, it's a computer shroom. Before you press the down arrow, I'm not criticizing linux, but I might be criticizing (certain implementations of) a programming language.
Shocking, you have ze physical access, you can interrupt ze boot process....
Just saying break=sidewayz or various real options or (my old favourite which used to work, but doesn't do so well these days was init=/bin/bash).
Just a few days ago I used this to add myself to /etc/passwd before letting the system reach multi-user mode.
I must admit it's a bit embarrassing for whoever wrote the comparisons in that bootscript, but this is really nothing to see, move along...
Having thought about it a bit more, really the only plausible case I can come up with is if you decided you wanted to prevent unauthorized folks accessing your system but you didn't want to lock the whole thing up, so you just locked away the main system but left the monitor and keyboard on your desk. Then you misunderstood the purpose of disk encryption and decided to use it as an access control mechanism, believing that the decryption prompt on boot would effectively prevent anyone accessing the system at all (assuming you always locked the screen or shut it down when walking away). And, probably (I'm still thinking about this bit) realized you had to set a bootloader password for this approach to be 'effective'.
Of course, what you should actually have done is set a firmware (BIOS) password.
Quite honestly, I doubt Linus even noticed this in passing. It's kinda outside his normal jurisdiction. If you're seriously curious, you could email him and ask; it's not like his email address is top secret or anything.
Note that I don't actually recommend sending that mail ... I suspect his answer (if any) would be along the lines of "Why are you bothering me with this crap? If you had done even 30 seconds of the most basic of research, you would know that my name is nowhere near that codebase."
This post has been deleted by its author
"Gone in 1 second: Taking a hammer to your computer - The simple exploit, which requires physical access to the system, exists due to a bug in Linux security experts who feel the need to make big news out of every vulnerability. ..."
I get the importance of the bug and also that it needs fixing, but can we please at least make a distinction between security holes, which require physical access and those that don't? Anyone who can get this close to the computer may as well destroy it by conventional means, steal it or replace it with another depending what the true nature of the attack is. That these bugs get the same attention as those, which can be triggered over a network, is simply unreasonable, because they are far less critical in real life. Security holes in a network can get exploited by millions of people and with bots are we seeing the numbers going into the hundreds of millions. You sure don't get that many opportunities with physical access, do you now?
One of the more popular arguments against this being an exploit of import is: 'it requires physical access to the machine.' What sort of benefit do you think full disk encryption provides if not protection against personae non gratae with physical access to hardware? If you're concerened about the server side of things, well that might be another matter; if we assume a server to be always on, then the disks are already decrypted and data is always potentially open to an intruder in the room. But the brunt of any cryptsetup exploit will be felt on personal computers, business workstations and kiosk machines, because that is exactly what cryptsetup was meant to protect.
I'm not sure whether the majority of comments deprecating this discovery stem from ignorance of cryptsetup's actual purpose, or whether they're misguided attempts at downplaying a weakness in a goup's technological investment... In either case, it provides a hint as to why Linux is not taken seriously on the desktop, since there exist a large number of users who apparently don't take the desktop side seriously at all.