1

There have been reports yesterday about a new security vulnerablity:

The news reports all say things like the vulnerability can "allow a hacker to install malware on a locked-down Linux system", can "bypass all security of a locked-down Linux machine", and can "bypass password protection on your computer". The actual vulnerability itself is CVE-2015-8370, and has been written up by one of its discoverers:

Whilst the news reports are hyperbolic, talking of vulnerabilities in Linux, the report by Marco and Ripoll is very technical for the non-programmer to absorb, descending into colourized source code or GRUB2 and 40-character-long strings of numbers and letters within the first page.

I'm just an ordinary "security guy". I keep my applications and operating systems up to date with security patches. So, without the hyperbole from the news reports, and without baffling me with source code and hexddumps:

  • Is there any immediate action that I should take? Is there any immediate action that I can take?
  • What is the risk to my personal systems at home?
  • What is the risk to my servers at work? If someone had IPKVM or ILO access, for example, could this be exploited?
JdeBP
  • 68,745
Henry WH Hack v3.0
  • 462
  • did you try it and did it work for you? Where did you read it? Does it have some name? – Jakuje Dec 17 '15 at 19:43
  • 1
    This is a vulnerability in the Grub bootloader and it is already patched in Debian and most other major distros... – jasonwryan Dec 17 '15 at 19:44
  • 1
    Well why did you ask about your browser and programs? They are completely unrelated... – jasonwryan Dec 17 '15 at 19:56
  • This post is completely nonsense as it is. – Rui F Ribeiro Dec 17 '15 at 20:21
  • 4
    It appears OP has already asked this question and accepted an answer at https://security.stackexchange.com/questions/108428/what-is-happening-now-with-the-gnu-linux-backspace-key-security-vulnerability , perhaps just fishing for a second opinion here? – clarity123 Dec 17 '15 at 21:04
  • 1
    Actually, it was asked here first. Have an improved question. – JdeBP Dec 17 '15 at 21:45
  • 1
    @JdeBP - that was a good edit. – mikeserv Dec 17 '15 at 23:51
  • @MichaelMrozek - this question was posted here first. Seems like you should be closing the other one, don't you think? And anyway - it went through the normal close process and received the necessary three Leave Open votes so that it might remain open. And then you just come in here and modhammer it? That's pretty screwed up. So I guess basically it doesn't matter what the community thinks if you disagree, huh? – mikeserv Dec 19 '15 at 02:52

2 Answers2

4

This kind of problem is inevitable. Or, at least, it is doubly probable. When people talk about grub as a necessity they almost always bring up things like keeping the kernel image on an encrypted disk, or SecureBoot keys. They usually say that you couldn't handle those things otherwise, that you need an intermediate loader in your boot process to interface between your firmware and your kernel.

While it's true that grub can read many different kinds of filesystems, has built-in networking support, and supports EFI SecureBoot shims, I think it's a little weird that others consider these are good things. I consider them redundant, overly complicated, and a second attack surface.

Once upon a time it was necessary - though it has always been stupid - it was once necessary for the firmware to call an intermediate loader binary that could then call the kernel. It was necessary because BIOS was too old and stupid to comprehend any practically usable system kernel you might otherwise prefer it to load. The idea of a bootloader was just a workaround for stupid firmware in the first place.

For typical machines manufactured anytime within the past five years or so this is no longer the case, though practically every linux distribution still does it by default. BIOS is dead - the (U)EFI standard has practically replaced it altogether, and a firmware of that variety has no issues directly invoking your system kernel - no bootloader necessary. In fact, if you were to compile in your initramfs you could just name your kernel image /boot/EFI/BOOT/BOOTX64.efi and your computer would boot it automatically.

And all of the stuff about grub being necessary to handle encrypted filesystems and etc is hogwash, plain and simple. As I see it, the fewer programs there are that can unlock a locked disk, the more secure that lock becomes. So if you kept your kernel on a plain filesystem - such as the very basic FAT fs mandated for your EFI system partition - then the (U)EFI could load it and the kernel would unlock your disk, of course.

You can also self-sign your system kernel and install those keys to the firmware's NVRAM so the firmware would directly validate your kernel image's certificate at every boot.

You can do this without grub - you can do this easier without grub.

So if you want to worry about the extra complexity and extra attack surface of a second OS kernel then you should update your grub chainloader immediately. If you don't, you should uninstall it.

The answers at the Information Security site seem to downplay the vulnerability involved with this issue. They say that it's not an issue because you need physical access to the machine to exploit it, and that if you've got that then the machine is yours anyway.

I disagree. If anyone can walk up to your computer, power it off and on, circumvent your boot-menu password by hitting backspace 28 times, and then afterward have access to your disks via grub's command-line and to your network via your MAC, then that's a problem.

mikeserv
  • 58,310
  • 1
    Agreed. With UEFI-based firmware, there is absolutely no valid reason to continue to use GRUB. – fpmurphy Dec 17 '15 at 23:13
  • Well, I mostly agree with the accepted answer at Sec.SE. Someone with physical access to your computer can just log into your UEFI and install whatever certificates are necessary to load a compromised kernel. It is easy (very easy on a desktop PC) to reset the UEFI password. With GRUB nowadays you can have an encrypted /boot partition, so your kernel and initramfs are safe. While certainly not trivial, this is very useful. You can also have scripts to check whether the EFI loader was tampered, as soon as /boot is unlocked, and before unlocking your actual root partition. – Marc.2377 May 29 '17 at 00:22
1

How to boot Linux without a bootloader. Untested by me personally, but might be a good starting point.

Shannon Spires
  • 19
  • 1
    that's good, but it mentions that the boot process is less interactive, which isn't necessarily true. EFI is an interface - and it can run compiled C programs if the binary is of the right format. The one such I use is rEFInd which is a boot manager - not to be mistaken with a boot loader. rEFInd finds your boot kernel and passes your boot selection to the firmware to boot - its my BOOTX64.efi. so I get the menus - nice looking ones - and configurability of a loader without the nonsense. I usually point people here. – mikeserv Dec 17 '15 at 23:50