Gone in 70 seconds: Holding Enter key can smash through defense 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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
