GRUB2, you're getting too bug for your boots: Config file buffer overflow is a boon for malware seeking to drill deeper into a system

An annoying vulnerability in the widely used GRUB2 bootloader can be potentially exploited by malware or a rogue insider already on a machine to thoroughly compromise the operating system or hypervisor while evading detection by users and security tools. This affects mainly Linux-based computers and devices, where GRUB2 is …

[sitta_europea]

Seems like a non-story.

If I have administrator acess to the machine, I can do what I want with it anyway, no?

That includes installing stuff of my own making to be run at boot.

There'd be no need to make life harder for myself by trying to exploit a heap overflow in anything.

[Jim Mitchell]

The article does cover this.

[Nate Amsden]

Sure does..

also seems to affect those who specifically use secureboot(since without that I mean any admin can set any kernel or whatever to load in grub signed or not), I'm not sure how many do, I don't think I have had it enabled on any of my systems. Just checked my personal Linux laptop and it is not enabled(https://techoverflow.net/2019/05/23/how-to-check-if-secure-boot-is-enabled-on-ubuntu/ ), and checked one of my ESX Ubuntu VMs and says EFI not supported, so that rules out an issue on any of my 700+ linux VMs and probably the windows VMs too. Checked a HP Gen10 system with Ubuntu 20 and says it's disabled, Checked an older Gen8 with Ubuntu 16 and says EFI not supported.

An interesting question for me that wasn't raised in the article not sure if it is an issue or not, but if/when this cert is revoked by the vendor(I assume vendor like HP, Dell, etc) could it prevent the system from booting(assuming Secure boot is enabled) if the grub update isn't already applied?

[A Non e-mouse]

An interesting question for me that wasn't raised in the article not sure if it is an issue or not, but if/when this cert is revoked by the vendor(I assume vendor like HP, Dell, etc) could it prevent the system from booting(assuming Secure boot is enabled) if the grub update isn't already applied?

Yes. And it'll aslo prevent any old rescue/install media from working too.

[Steve McIntyre]

Yes, as I wrote in the Debian advisory linked from the article. It may take a while for the dbx update to roll out, but it is qiute likely to cause trouble when it lands.

[JavaJester]

Install your own boot loader

If you are able to modify the grub config file, wouldn't you modify it to have the system run an evil bootloader rather than stuffing random crap into the file to trigger a buffer overflow to (drumroll...) run an evil bootloader?

[NetBlackOps]

Re: Install your own boot loader

I think of it as yet another method to maintain residence in an already compromised system.

[YetAnotherJoeBlow]

Re: Install your own boot loader

It is a savings account for when the rent gets raised.

[Anonymous Coward]

Sure, but this method is better at avoiding detection and eradication than an OS level attack. If you want your threat to sit dormant and persist across scans and upgrades, this is the way to do it. Very handy for espionage or sabotage.

[IGnatius T Foobar !]

I wouldn't worry about this.

I wouldn't worry about issues with GRUB. It's only a matter of time before systemd handles booting. :)

[oiseau]

Re: I wouldn't worry about this.

... a matter of time before systemd handles booting.

Hmmm ...

Not if you ran on Devuan or a Devuan based Linux distribution.

Or if the rest of the Linux ecosystem finally/eventually comes to its senses, realises the evil abomination Poettering's really child is and does away with it.

Permanently.

O.

[jake]

Re: I wouldn't worry about this.

Or just use Slackware.

[Ozan]

Re: I wouldn't worry about this.

Slackware not only lacks systemd it also uses good old lilo.

[jake]

Re: I wouldn't worry about this.

Or eLilo, if you're using EFI.

GRUB is an option, though.

[jake]

Re: I wouldn't worry about this.

Over my dead bootloader.

(For those not in the know, there is no way for the systemd cancer to preempt the bootloader unless the operator of the computer in question wants it to happen. The bootloader loads the kernel, which transfers control to the init, which does not have to be the systemd cancer.)

[chuckufarley]

Re: I wouldn't worry about this.

"...which does not have to be the systemd cancer."

Devil's Advocate: That's right, kids! It can be the cancer of your choice! All you have to do is not choose!

[jake]

Re: I wouldn't worry about this.

But can you name another init that is a cancer like systemd?

Consider: systemd takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host. That sounds an awful lot like a cancer to me ...

[chuckufarley]

Re: I wouldn't worry about this.

I didn't say it wasn't cancer, I just implied that by not choosing more cancer would follow because not choosing is a choice in and of itself.

[chuckufarley]

So that was...

...Why I had a bunch of grub updates for all of my boxes today. Well they are patched and rebooted.

[jake]

Hang on a second. Something smells funny.

Shirley this is a hole in SecureBoot, not in GRUB2?

Yes, GRUB2 has a bug that makes exploiting the hole somewhat easier ... But any bootloader can easily[0] open the same hole in SecureBoot, so blaming GRUB2 for this seems a trifle misguided.

Besides, if I have access to the hardware I own it anyway (as pointed out in the article).

I also note with interest that there isn't any mention of this at https://www.gnu.org/software/grub/ ... and the latest download release is dated July 5th of last year.

I'm probably missing something. Wouldn't be the first time. Anybody have any input? I'm buying.

Note: I don't have a dog in this race ... I don't use GRUB.

[0] "Easy" is subjective, and bootloaders aren't exactly rocket surgery. Bear with me.

[brotherelf]

Re: Hang on a second. Something smells funny.

Where's the SecureBoot flaw in there? It hands over control to a boot loader with a valid digital signature, which is the only notion of "trusted" at that point, and the fix on SB's side is a revocation list that invalidates that particular signature.

The flaw, if any, is that buggy software got signed, but putting that at SecureBoot's door is like saying CAs should miraculously not issue and revoke certificates for sites running old Wordpress versions.

I would be entirely unsurprised if there are boot loaders which have gone through formal verification, i.e. are mathematically proven to work correctly (on an abstracted machine model, i.e. still vulnerable to compiler and CPU microcode bugs)

[jake]

Re: Hang on a second. Something smells funny.

Read the Eclypsium PDF on the subject here. First sentence of the second paragraph.

"The vulnerability affects systems using Secure Boot, even if they are not using GRUB2."

[mderouss]

Be nice if they could make it secure *and reliable*

So I installed a Grub update today on my 20.04 Ubuntu box. I'm not certain it covered CVE-2020-10713, but it performed an effective DOS attack on my machine all by itself without any intervention by 'bad actors'. A quick look at Git showed that 28 commits had changed at least 87 files, possibly far more. It would appear that the update was made available just a few hours after this bunch of commits was applied. Over the course of the last couple of years, issues with GRUB have become common for me. Fortunately the 'Boot Repair' tool can sort them out by reinstalling a working copy of GRUB.

So I'm led to wonder two things - why does such a critical component not provide a rock-solid recovery mechanism in it's own right ( or better, a rock solid installation system ), rather than having to rely on a third party tool which seems to do a better job of analysing the target system, and why, given it's propensity for failure, are massive batches of changes being shipped mere hours after being pulled into mainline ? Possibly the distro has more to answer for than GRUB for the latter point, but the lasting impression is that there's more wrong with GRUB than simply some buffer overflows.

[hmv]

Re: Be nice if they could make it secure *and reliable*

Hmm ... it's possible that there's something funky about your machine rather than the update - I've upgraded two Ubuntu machines this morning (although only one was rebooted) without an issue. And I've certainly not seen any recent booting issues after a grub update.

But yes, I'd certainly agree that making booting more bullet-proof would be useful.

[Marjolica]

Re: Be nice if they could make it secure *and reliable*

Devuan user here. System did an unattended-upgrades at 9:45 this morning (that installs security fixes) and provided a new grub-common (grub-common_2.02+dfsg1-20+deb10u1_amd64.deb).

However just did a hibernate (that restarts the machine and reloads grub) and everything is still working OK.

Ubuntu is Debian based, as is Ubuntu, so seems like you have a specific problem. If you don't reboot that often then all sorts of other changes you made since last reboot might be triggering it.

[Anonymous Coward]

Yeah, fuck, I recently upgraded my HP laptop to run Ubuntu , single boot, what do I do ???

I am a Stable Genius, but have no clue whatever........................ to do about this!!

[Lunatic Looking For Asylum]

Nothing :-)

They will roll out the patches to Ubuntu (if they haven't already) and it will automatically update as is Ubuntu's wont.

If you are really desperate to apply the patches, open a terminal and :-

sudo -i

apt-get update

apt-get upgrade

and that should apply all the latest and greatest.

My preferred method is :-

apt-get dist-upgrade which is a bit more intense that a mere upgrade ;-)

YMMV

Are you a Stable Genius because you look after horses before they bolt ?

[Anonymous Coward]

Re: Nothing :-)

Big Thanks & Kudos for your reply.

And, uhm, Stable Genius because I close the stable door after the horses bolted from a burned down stable, I am NOT an IDIOT !!!!

[Version 1.0]

Buffer overflow, a "traditional" issue

In the early days of writing code I was debugging an interrupt driven keyboard reader for ZCPR and I saw buffer overflows, it was an easy fix after I woke up in the morning after dreaming about the code to build a circular buffer and watch the pointers. I've never seen buffer overflow issues since because I had to fix them very early in my life - I'm guessing that young coders these days are taught new languages all the time, but not how to code properly? Applications are getting larger and larger, it's not a problem these days because everyone has at least 5Gb of memory, larger applications have more room for bugs and larger buffers so there's no need to worry about buffer overflow ... until it overflows.

[Lunatic Looking For Asylum]

Re: Buffer overflow, a "traditional" issue

I think 'young coders' tend to JFGI and cut and post the code samples they find which are usually the best examples of how not to write perfectly formed, commented and structured code.

[Steve Graham]

Bloat

Grub2 is one of those components of the Linux ecosystem which has loads of functionality to cover edge cases which don't apply to the vast majority of hardware. The bigger the code base, the greater incidence of bugs.

For some time, I've been considering a migration to extlinux. It boots a kernel off an ext2/3/4 filesystem on a SATA drive, which is all I've ever needed.

[Lunatic Looking For Asylum]

And Debian fluff it of course...

The update for grub2 released as DSA 4735-1 caused a boot-regression

when chainloading another bootlaoder and breaking notably dual-boot with

Windows. Updated grub2 packages are now available to correct this issue.

For the stable distribution (buster), this problem has been fixed in

version 2.02+dfsg1-20+deb10u2.