0-Day GRUB2 Authentication Bypass Hits Linux (hmarco.org) 144
prisoninmate writes: A zero-day security flaw was discovered by developers Ismael Ripoll and Hector Marco in the upstream GRUB2 packages. GRUB2 did not correctly handle the backspace key when the bootloader was configured to use password protected authentication, thus allowing a local attacker to bypass GRUB's password protection. Versions from 1.98 (December, 2009) to 2.02 (December, 2015) are affected. At the moment, it looks like only a few distributions received the patched GRUB2 versions, including Ubuntu, Debian (Squeeze LTS only) and Red Hat Enterprise Linux 7.
Slackware for the win (Score:2, Interesting)
Seriously how can a bug like this hang around as basic input validation is something that should be done.
Re:Slackware for the win (Score:4, Informative)
Sadly slackware also appears to be slowly winding down. Sure its still being updated on an ad hoc package by package basis, by there hasn't been a full distro release for 2.5 years now. Thats not a good sign.
Re: Slackware for the win (Score:1)
The natural migration from Slackware is to a BSD. I migrated from Slackware to NetBSD in 1999.
Re: (Score:2)
Only superficially. When you get into the guts of administering the OS's then slackware is a lot closer to other linuxes than it is *BSD. Also the BSDs suffer from a lack of support. You might find that a linux program compiles from source on *BSD but often you'll find it doesn't without hacking it around a bit. Also the linux emulation layer - whatever its called - on BSD I always found a bit flaky.
Re: (Score:2)
Have you used a BSD since 1999? The ports system takes a bit of getting used to, but it works more than fine. But it's a server distro, I wouldn't dream of using any of them as a desktop OS though, but that's not what they're designed to do...
Re: (Score:2)
It has been a while since I've used FreeBSD, I liked it, but as you say, its not a desktop OS so I stayed with linux.
Re: (Score:1)
NetBSD isn't really a server distro. It's the most general-purpose of the three main BSD's. The point in NetBSD is portability. Portability squeezes warts and bugs out of software that is coded too close to a particular architecture. When you download the source code for NetBSD, you're downloading the source for every architecture it runs on. With Linux it's typical that every 'distribution' is more or less tweaked to a particular architecture.
And anyway, my comment about NetBSD being similar to Slackw
Re:Slackware for the win (Score:4, Informative)
Slackware is not winding down. There has not been a release because there has been little reason for one. With so much in flux Systemd, X/Wayland, GCC 5 stabilizing, and XFCE Slackware's 2nd of 2 DE's having only recently itself having a major release 14.1 has aged well. I think figuring out where udev/eudev were going also has held things up a bit.
The changelog has been very active the past couple months. Patrick is making noise about 'betas' etc and the other developers like Robby and Eric are also hinting. A new release is coming.
What you have to realize about Slackware is, releases are not done for their own sake. They done for the sake of major changes and improvements. Slackware only implements major changes / forklifts when its clear they won't be walking back those changes or replacing them again with something else in the near future. Slackware really takes stability and consistency very very seriously.
The 'faster' thing move in the Linux ecosystem the longer the Slackware team has to wait for the dust to settle.
Re: (Score:2)
"little reason for one"
Seriously? The rate hardware changes these days theres a good chance the base release from 2013 won't boot on an up to date PC and if it does it might not be able to run the network hardware. In which case how exactly you do you expect someone to update it to current?
Re: (Score:2)
Re: (Score:2)
Because many distributions have trouble booting via UEFI and more and more systems are shipping without legacy/MBR boot support and can only boot via UEFI.
UEFI brings some nice improvements but motherboard manufactures typically only test with Windows and good UEFI support hasn't been a high priority until very recently for many Linux distributions.
Re: (Score:1)
From Slackware 14.1 release notes:
One of the big changes in Slackware 14.1 is support for systems
running UEFI firmware (x86_64 Slackware edition only). We've added
several new packages for UEFI, including elilo, GRUB 2, and efibootmgr,
and all of the installation media supports booting under UEFI, as do
the USB boot sticks generated during installation. At this point
there is no support for running the system under Secure Boot, but a
dedicated user could add their own Machine Owner Key, sign their
kernels, modules, and bootloader, and then use shim to start the
bootloader. We'll be looking into adding support for this in the
next development cycle. Documentation for installing on UEFI machines
is provided in a README_UEFI.TXT found in the top-level Slackware
directory.
Slackware ISO images (both the ones available online as well as
the discs sent out from the Slackware store) have been processed using
isohybrid. This allows them to be written to a USB stick, which can
then be booted and used as the install source. This works on machines
running both regular BIOS as well as UEFI.
Re: (Score:1)
Re: (Score:2)
Its a good thing the current release 14.1 has UEFI support already.
Re: (Score:1)
2.5 year old beta software support. Good luck.
Re: (Score:1)
Pure BS. I'm running fedora23 on a core 2 duo I built in 2007 with absolutely no problems. Even upgraded it with dnf system-upgrade without trouble.
Re: (Score:3)
It just has taken longer than usual because upstream is in great turmoil and some hard decisions needed to be made regarding:
ConsoleKit/systemd (consolekit2), udev/systemd (eudev) and KDE (probably still KDE4).
Re: (Score:2)
Re: (Score:1)
Seriously how can a bug like this hang around as basic input validation is something that should be done.
For some strange reason folks these days insist that bloated high level languages like C/C++ are a good choice of language for real low level problems, leading to bootloader designs the defy explanation, because the developers suited to making a high level language work in this instance are not the typical developers that have to deal with unconstrained input.
In car analogy terms, its what you get when you hire a car mechanic to design an oil tanker.
Re: (Score:2)
C was designed in the 1970s specifically as a language to replace assembler for low level development and even today almost all OS kernels including linux, windows and OS/X are written in it. Buy a ticket on the clue train when you get a chance.
Re: (Score:2)
C was designed in the 1970s...
Yes.
... specifically as a language to replace assembler for low level development
No.
The C crowd has been claiming this for awhile, but not since the 70's. It wasn't until the 90's that the C crowd started insisting that C was a low level language. I've been banging keys through all of this period. You are wrong.
and even today almost all OS kernels including linux, windows and OS/X are written in it.
Not entirely, but you pretend different.
The real problem here isnt your ignorance about C, its that you have no idea what "low level" means, just like that wave of 1990's C programmers.
Buy a ticket on the clue train when you get a chance.
I'm already on the clue train. Tickets cost knowledge. Hope that someday you can a
Re: (Score:2)
The C crowd has been claiming this for awhile, but not since the 70's. It wasn't until the 90's that the C crowd started insisting that C was a low level language. I've been banging keys through all of this period. You are wrong.
Taken from K&R first edition calls C "not a very high level language", while second edition calls C "a relatively low level language" (page 1). I assume they know better than you.
The real problem here isnt(sic) your ignorance about C, its that you have no idea what "low level" means, just like that wave of 1990's C programmers.
I think we know what "low level" means, and it means something other than what you think it does.
Re: (Score:2)
Sorry K&R first edition was published 1978 -- "70s". Considering most people considered K&R's book the authority on C at the time, and they played a big role in writing C as we know it, I think I'll take their word for it over yours.
Re: (Score:2)
OTOH, what do you mean "low level". Assembler code is generally executed via a lower level of microcode (though I think it's burned into ROM during the writing of the CPU chip. (Read ROM as descriptive, not as a separate chip.)
So I have no problem calling C low level. These days I normally program in Python or D. I gave up on assembler the sixth time I had to rewrite all my programs.
Re: (Score:2)
" I've been banging keys through all of this period. You are wrong."
All that proves is that length of service doesn't always give rise to knowledge.
"Not entirely, but you pretend different."
Apart from a small amount of assembler - yes , entirely.
"I'm already on the clue train."
Apparently the one you're on has yet to leave the station.
Re: (Score:2)
Real bootloaders are written using toggle switches and pushbuttons, not keyboards!
Re: (Score:2)
C++ may (or may not) fail to produce bloated executables, but it is a bloated language. It's full specification is now considerably larger than is that for Ada, which when it was launched was roundly denounced for having a bloated specification. (For that matter, except for string handling, Ada is a generally nicer language than C++. Unfortunately, I do a lot of string handling. Even more unfortunately, C++ handling of unicode strings is so poor that I generally choose some other language. Usually D or
News for nerds? (Score:4, Insightful)
Is this even an issue?
It's a password on the boot loader. It's not encrypting anything. If anyone is in the position to interact with a machine before the OS has loaded, they've probably got enough access to it that they can do whatever the hell they want, including booting the system off alternative media and replacing or reconfiguring said boot loader.
Re:News for nerds? (Score:4, Insightful)
Then why offer a password on a bootloader?
Re:News for nerds? (Score:5, Insightful)
I can see where a boot password would be handy for a kiosk or similar setup where the machine is out in public space, and I'd definitely want it locked down to some degree. BIOS boot options as well.
For a server room, this is no big deal.
Re: (Score:1)
Re: (Score:2)
more features for a smaller cost.
Re:News for nerds? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
Its news, but it's not as big as many people think.
It's also not a zero-day. When a disclosure happens before the exploit, it's not zero-day. And when a patch is already out, like for Red Hat, it's definitely not zero-day.
Is it a bug that needs fixing? Absolutely. But this isn't anything to worry overly much about. There are a lot of other things to worry about with grub2, which isn't exactly the pinnacle of elegant design.
Re: (Score:2)
Yep. The term "zero-day" indicates that the bug was discovered because it was being exploited in the wild. I saw no specific mention of this, so it looks like the article got it wrong, and the summary picked up on that incorrect usage.
Re: (Score:1)
Well, if you've got a fully encrypted drive and a passworded bootloader, it can actually make things pretty difficult to access even if you can boot alternative media.
Re: (Score:3)
Re: (Score:1)
That makes sense to me.Another good reason to have a password, and it would also mean that this bug would be useless if encryption is used.
Re: (Score:2)
Re: (Score:1)
This is not security (Score:4, Insightful)
In the majority of cases if you are interacting with the boot process then you have physical access to the machine. So unless GRUB is managing disk encryption you have access regardless of the password in GRUB. This is security theater, not real security and breaking it is not accomplishing anything significant.
Next Story.
Of course this is security (Score:3)
That's so silly - physical access to the machine doesn't mean anything per se!
What if you can't take the machine apart inconspicuously because the case is sealed. What if you have only 3 minutes before someone else comes by? Security is not black and zero at all.
One can easily even use an AVR that'll replay the keypress sequence over USB (posing as a keyboard) on a button press. This is something completely different than taking the machine apart to clear CMOS or whatever.
BTW, can you have UEFI trusted boot
Re: (Score:3, Interesting)
What if you can't take the machine apart inconspicuously because the case is sealed. What if you have only 3 minutes before someone else comes by? Security is not black and zero at all.
That is like the most contrived example ever. Perhaps you shouldn't take use cases from Hollywood flicks?
We are talking about the boot process, the computer wouldn't be shut down if the user was away for three minutes.
More realistic scenario would be laptop left in hotel room and an option would be to just steal the laptop and have all the time in the world.
Re: (Score:2)
That is like the most contrived example ever.
It's a very common example for many locations, assuming "sealed" means a lock and cable on a public-use computer.
We are talking about the boot process, the computer wouldn't be shut down if the user was away for three minutes.
Physical access does include the power button. And it's not just "the user" you have to worry about, but *anyone* just passing by. Of course if the machine was screen-locked with a user logged in, it might arouse suspicion if it's later found turned off or at the login screen.
More realistic scenario would be laptop left in hotel room and an option would be to just steal the laptop and have all the time in the world.
More common for home users perhaps, but this doesn't mean it's the only scenario that grub should be designed for.
Re: (Score:1)
Re: (Score:2)
Sometimes, physical access to the machine is the whole point of having that machine around. You provide local keyboard, mouse, monitor or even worse things to annoying and/or weird walking meatsacks called "users".
Re: (Score:3)
Now with GRUB not really being password protected, an attacker can easily get to a privileged shell without a password
true, but your root partition is encrypted with a good LUKS passphrase so all they can do is see your disks, similar to a USB boot. If you already password-protected your BIOS, have a physical lock on the battery, and epoxied all your ports shut, then, yes, this is a higher level of concern. Probably most people don't fall into that scenario, though (and if they do, trusted boot is a bette
Re: (Score:1)
Not even. The password on boot is usually used to prevent editing or commandline.
It CAN be used to password-protect a specific device, but that's hardly a secure approach. The device is still there.
Any device that has strict security requirements where they restrict usage would have it on the OS level, where you can have tons of security libraries and best-practices at play.
.
There are some scenarios where restricting boot can make sense outside of "steal your data." Think about a computer at an office that
.04 versions? (Score:2, Funny)
They certainly set a blistering development pace.
Re: (Score:3, Informative)
Re: (Score:1)
Versions from 1.98 (December, 2009) to 2.02 (December, 2015)
How, exactly, can you call this a "0-day" exploit if the hole has existed for six years?
Re: (Score:3)
Because GRUB developers had 0 days to develop a patch because it was already known from the outside. They can exist far longer and still be zero-day.
Re: (Score:2)
Grub does, in fact, go 1.98, 1.99, 2.00, etc.
Re: (Score:2)
Are you kidding me? Cue a queue of linux fanbois explaining how this isn't a big issue,
shrug. It's deeply wretched, but it's a non issue for a lot of people. If you have no machines with GRUB and password protection then it doesn't affect you. I don't know anyone it affects, personally.
Still, though how the fuck do you mess that up in 2015???
Re: (Score:2)
bear metal
That's some grizzly steel right there.
Re: (Score:1)
Because it's not a "heavily used" part of the system, and it's code no one wants to have to look at. (boot loaders are very ugly shit.)
The troll awakens (Score:2, Funny)
This was a deliberate move by the FSF, because computers that need passwords aren't really free, are they?
Re: (Score:2)
This was a deliberate move by the FSF, because computers that need passwords aren't really free, are they?
You joke, but RMS hates passwords on computers: http://www.oreilly.com/openboo... [oreilly.com] He might as well say "A train that is stuck to the tracks isn't really free to move. Remove the tracks!"
Re: (Score:3)
This was a deliberate move by the FSF, because computers that need passwords aren't really free, are they?
Title is obviously wrong. As you should well know, Grub is Not Linux!
Seriously, the title is wrong, since Grub is a pre-OS environment used to load the actual operating systems, including not just Linux, but Windows and the BSDs. Saying this is a Linux bug is like blaming Microsoft for a BIOS bug.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Also it's a very obscure and generally unimportant feature. The only way a bootloader password could provide meaningful security is on a computer in a secure kiosk, where random users can get to the keyboard and but not the insides.
What about systemd-grub? (Score:5, Funny)
The new systemd-grub leverages a pre-boot, machine-level dbus interface to policy-kit and systemd-logind, which will handle this for you. Why are people still in the dark ages with bootloader passwords?
Re: (Score:2)
I'm sorry, but I think the module you wanted for systemd was bootloaderd.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
GRUB already is the systemd of bootloaders.
They already did that; lilo was much easier, and simpler than grub; but they went with grub anyway.
I don't want a GRand Unified Bootloader for my Linux distro; I just want something where it's easy to tweak to boot parameters and doesn't involve the voodoo like parameters of GRUB, something like lilo.
Re: (Score:2)
Give extlinux a try. It's still around and is very lilo like, simple config file vice a huge maze of support scripts generating the actual complex configuration files that grub2 uses.
Re: (Score:1)
LI
Re: (Score:2)
Yawn.... (Score:4, Insightful)
If someone has local access, they OWN the machine already. This is a minor inconvenience as zero security is given with a grub password anyways.
Re: (Score:2)
If someone has local access, they OWN the machine already.
Using that logic, nobody should be required to enter a password at a local console.
This is a minor inconvenience as zero security is given with a grub password anyways.
"Hey guys we have this new password feature, but its completely useless so don't use it or ever rely on it."
tl;dr (Score:4, Informative)
press backspace 28 times [enter]
write_word 0x7eb514e 0x90909090[enter]
normal[enter]
Enter 'edit mode'
append init=/bin/bash to the linux entry
F10
Re: (Score:2)
1. Turn on computer.
2. Choose OS.
3. Boot.
Because NOBODY uses the grub password feature.
Re: (Score:1)
Re: (Score:2)
that's what init=/bin/bash is for. You boot directly to bash shell with root privileges bypassing all authentication. Then you can either create a passwordless alias for the root account, or install any rootkit you like.
Re: (Score:2)
the kernel loads normally. It's the init system (which is already userspace) that gets hijacked. The whole authentication system runs on userspace side - and in this case isn't run, replaced by plain bash. You still need to issue 'mount -a' to mount all the filesystems but they work okay.
Geebus (Score:1)
There are enough REAL security issues floating around without getting our panties all in a wad over an issue that requires PHYSICAL access to the Console and Keyboard on a machine that has already been rebooted ...
Along the same lines, even after this 'Zero-Day' is repaired, if I can access the Console and Keyboard, I can access the Boot Menu, and boot from a Thumb-Drive and then do everything I could do via the Grub2 Bug.
Sheesh !
-- kjh
Re: (Score:1)
Both?
No surprise here (Score:1)
No surprise here. GRUB2 has always been a POS. I knew this would happen when all major Linux distros started forcing their users to use GRUB2 (not unlike the systemd fiasco). Yet, my Linux machines all use GRUB Legacy and are immune.
Re: (Score:2)
GRUB 2, same as systemd, suffers from gross KISS violation. GRUB 2 also suffers from the "Second System Effect", where they put in everything and the kitchen sink. Systemd has the same problem, but _they_ managed to make this basic mistake on the first try.
Good thing I use LILO! (Score:2)
Not so critical (Score:2)
An attacker with physical access and some minimal skill has won anyways.
Re: (Score:2)
Forget it. Lockpicking is not hard.
Slackware (Score:2)
Seems slackware.org is /.......
Ubuntu Fixed it! (Score:2)
Re: (Score:2)
But if you can get to interface with GRUB, that means it went through an interface (BIOS/EFI) which most likely you are likewise able to access. Any sort of pre-boot access gives you full control over the machine (make it netboot or mount a disk image to the virtual floppy).
Re: (Score:2)
ILOs must be secure by themselves, or an attacker can use them to reboot your system with a CD image or the like.