Back to the Future?
Do you have to do it at 88 MPH?
A pair of researchers from the University of Valencia's Cybersecurity research group have found that if you press backspace 28 times, it's possible to bypass authentication during boot-up on some Linux machines. The problem's not a kernel nor an operating system problem, but rather one in the very popular bootloader Grub2, …
I've never seen anyone use the password feature in Grub2, normally it just boots the OS directly. If you do a standard install of something like Ubuntu, you don't even see a Grub menu.
This is for when you have multiple operating systems installed, and you want to let the user pick which OS to boot, but you also want to make sure they can't edit the menu to add or remove items (operating systems). However, not many people are doing multi-boot these days. They tend to just run guest OSes in a VM instead.
Of course if you are using this feature and someone is sitting at the keyboard picking which OS to boot, it also means in most cases that they can do pretty much anything they want with the hardware anyway.
"Of course if you are using this feature and someone is sitting at the keyboard picking which OS to boot, it also means in most cases that they can do pretty much anything they want with the hardware anyway."
Exactly this. If the blackhat has physical access then all bets are off.
It could be an issue for kiosk setups, where the computer itself is locked up in a cabinet (so the ports are inaccessible) but people can get to the keyboard. It could also be an issue in schools. I used to volunteer at a school where they would set BIOS passwords to lock the boot order and then put a padlock on the case to make it more difficult to get to the clear-CMOS jumper. Sure, you could break the dinky little padlock, but that attracts attention. Hitting backspace at the boot prompt doesn't.
"The rescue shell offers all manner of opportunities for fun, as it allows unauthenticated access to a machine and the ability to load another environment."
Orly ? Unauthenticated access ? How so ?
Sorry, but if I can see grub prompt that means that server was down, I have full access to either serial or graphical console and at that stage perfectly capable of booting server from USB stick or image redirection. Why would I care about password on something that can be easily bypassed ?
Some cases have intrusion detection switches. I can wire that to the erase CMOS nvram pin. Now I can close the case, configure the BIOS to boot, but only allow changes to the boot order with a password. Next up, enable grub's password feature so the boot options can only be changed with a password. Now encrypt the server's secret key and store the password for it in CMOS nvram.
The server's certificate is now more difficult to get at if the attacker has physical access. There are two more things you need to sort out: all USB ports should be disconnected (and wired to the mains). Also, add an X-ray detector and use it to trigger some thermite. (The police will first attempt access with a USB device, then take an X-ray to cut into the box without triggering the intrusion detection switch).
Now to actually use that grub password, you need a USB to PS2 converter inside the box, and use a bulkhead mounting PS2 connector to get the signals out.
Secure boot throws away any hope of security. Old style BIOS is sufficiently small and stupid that it cannot do much more than read and execute a boot sector. Secure boot is huge. The chances are that the copy you have is based source code released by Intel, with whatever additions the manufacturer's government insisted on plus two huge binary blobs from Intel big enough to hide something that can man-in-the-middle an ethernet port and provide remote exfiltration invisible from inside the computer.
Bit locker keys can be read by an external device via a 1394 or thunderbolt DMA channel. If all else fails, reset the machine and boot from an external device. The keys can often be found in memory left over from the previous boot.
Securing a computer against physical access by a rich and determined attacker is really difficult. Grub's password feature is only a significant barrier if you have covered all the other bases.
This post has been deleted by its author
"Secure boot throws away any hope of security."
Using a TPM / PIN with Secure Boot and Bit Locker is as secure as it gets on standard hardware. It's one of the best practical options there currently is, and certainly doesn't make things worse for security.
"Old style BIOS is sufficiently small and stupid that it cannot do much more than read and execute a boot sector. "
That's all it needs to do - the TPM won't allow release of the keys to allow execution of the boot sector if it has changed.
"hide something that can man-in-the-middle an ethernet port and provide remote exfiltration invisible from inside the computer."
All encryption solutions require the device to be in a secure state at point of installation. Once Bitlocker / Secure Boot is applied with a BIOS password, PIN, TPM lockdown, etc, such changes become much harder to achieve.
"Bit locker keys can be read by an external device via a 1394 or thunderbolt DMA channel."
Not without physical access to a powered on and authenticated machine. In which case they might as well just grab it from you while unlocked.
"The keys can often be found in memory left over from the previous boot."
RAM content degrades rapidly after power down. The window for such an exploit is seconds, and it's therefore not a practical attack if due care is taken.
... with a backspace key?
The whole idea of an embedded system is that it works without the assistance of a user. If grub is set to require a password on boot then after every power cut, some poor techie is going to have to trudge out to darkest nowhere, dismantle the box and solder in a keyboard before typing a password.
If grub is set to require a password on boot then after every power cut
Grub only requires a password if you wish to change the settings it's configured to use. If you don't give it a password, it waits for the configured amount of time, then boots whatever it's been set to boot.
.... my Mint installation offered an update to Grub2 yesterday. It was marked as an important security update but was also maked as a 'level 5' update: "Dangerous updates. Known to affect the stabilty of he systems depending on certain specs or hardware."
Because of this confusion, I blocked the update. I think I'll keep it blocked.
Grub updates are usually OK so long as you don't have a "custom" boot arrangement which you don't really understand.
That usually shows up as a prompt about what do you want the update to do, usually in terms of using the default package maintainer's config or your own (own! own!) and/or which drives to install the boot loader (MBR) on (almost a trick question as it often offers logical drives like /dev/sda1 in the list but you should only ever install on physical drives such as /dev/sda).
Also, and this is the bummer for some, most grub updates don't need a reboot. But unless you reboot there and then to test it, some weeks/months later if something is screwed up you will be forced in to booting and it borks, and you have forgotten all about this update.
So my advices is install it, if prompted keep current settings (and/or install MBR on the /dev/sda) and then do a proper clean reboot just to be sure.
"“Grub2 is the bootloader used by most Linux systems including some embedded systems. This results in an incalculable number of affected devices."
Actually most embedded systems are going to be using U-Boot or something similar.
And as someone using Linux on an embedded system, I'm in a pretty good position to tell you that the only way to affect boot-up with a keyboard is to beat the box to death with the aforesaid keyboard. It doesn't have a PS/2 connector. It's a USB slave so you can't connect a keyboard that way. And RS-232 is strictly debug-output-only unless you do some jiggery-pokery inside the box. This isn't frigging rocket science, people.
Is this a scare story put out by M$ to frighten people into not disabling "secure boot" and so not installing Linux?
If the Linux installation in question is being used for some industrial purpose then there will be physical ways of preventing access to it.
If it's a laptop then for someone to be able to do this they have probably stolen the machine first. In this case the owner has bigger things to worry about, the thief will probably give up once he sees that it doesn't run M$ and the operating system is not going to be able to defend itself anyway.
So the protection is (1) only buy a laptop that is only as powerful (expensive) as you actually need, (2) encrypt your private data and (3) keep it backed up elsewhere.
Don't think it is a scare story.
The patch wouldn't of been mentioned if it was.
Also, it's the first Linux vulnerability in a while that has not required prior knowledge of the root passw0rd.
Don't get me wrong, I'm sure M$ will nudge their media outlets into turning this into a scare story within a day or so.
"it's the first Linux vulnerability in a while that has not required prior knowledge of the root passw0rd."
For small values of "in a while":
The second one is, and has already been patched.
Like most Linux vulns, that one was patched before it hit the news.
Note that whenever there's a Windows hole in the news it usually says "Microsoft will start pushing out an update..." and when there's a Linux hole in the news it usually says "A patch is available". That's because Linux security holes usually get patched quicker than reporters can write about them while Windows security holes get patched on Tuesday.
Windows security holes get patched on Tuesday
That was once upon a time, and not that long ago. When MicroSoft were willing to let you dig up (at you own leisure), some information, other then "Fixes a critical flaw in Windows" about, any given Update. Now a days they come whenever, and unannounced.
"Note that whenever there's a Windows hole in the news it usually says "
Note that the vast majority of Windows holes have patches released before anyone knows about them!
The reality is that Windows has had a faster average time to fix (fewer days at risk) every year for the last decade compared to SUSE and Redhat Linux.
It is a legitimate concern since grub2 is used by many distros for multi-boot configurations. Just how critical it is depends on the distro and how it is configured. I will be watching for a some updates in the next couple of days and installing them.
Also, the bypass appears to require physical access to the box to hit enter 28 times in a row.
Also, the bypass appears to require physical access to the box to hit enter 28 times in a row.
Pretty much. You can probably do the same with a DRAC card or similar.
Noetheless, this can only occur at boot time, and the majority of systems I've seen have no grub password to be overcome anyway. While this is a somewhat embarassing bug, it's not something I'm going to lose any sleep over...
No, not really. grub is a generic bootloader, you can use it to boot anything. And this doesn't exactly root anything, it bypasses a very specific form of protection - as discussed upthread, the grub password really only protects the grub configuration, and is only useful at all in extremely limited circumstances. Drive encryption and firmware-level passwords are much more generally useful for limiting access to a system.
If someone can exploit this vulnerability they can also boot from a USB drive or a CD and have the same access. Vulnerabilities that require physical access to the machine, while important to fix, aren't actually worth getting worked up about. An attacker with physical access to a machine usually equates "Game over, man, game over" anyway.
And then there's the fact that in somewhere between 10 and 15 years of using Linux I've never seen a system with the vulnerable feature turned on.
For my personal systems and work laptop?
Change all the damned boot options you want. Boot off anything you'd like. My data is encrypted. Sure, you can nuke my drive and install windows if you want. I have backups.
On the servers? -- boot into SUM, change the root password. Reboot.
By the time you have a console login, my config management tools have already applied the correct one. Ta. You're in SUM? you can't get at the volume that has those tools.
Yes, this is an issue for specific edge cases (we don't use this as we physically control access) but there are some unique edge cases that need it.