Multiple GRUB2 vulnerabilities – 2021/03/02 rou
lists.gnu.org
lists.gnu.org
Before SecureBoot (grub is older than even EFI), all these vulnerabilities other than the USB one would be just minor bugs, since exploiting them would gain no extra access; having access to the grub command line meant you already had full access to the system, without needing to for instance exploit buffer overflows in the command line parser.
Is EFI considered old now? Man, I haven't even started using it.
But what I meant is: SecureBoot builds on top of EFI, and grub predates even EFI, so grub definitely predates SecureBoot.
Widows might be doing something interesting with it, but does it help in the case of dual boot?
I'm using Qubes OS myself so I don't think Secure Boot would ever be useful in my case?
For a typical laptop, Secure Boot plus Full-Disk Encryption (e.g. Windows BitLocker) makes it harder but not impossible for an "evil maid" - an attacker with temporary, undetected access to the hardware - to compromise the system. (Note that Qubes' VM isolation, per se, does not help in an "evil maid" scenario! - the evil maid typically never even turns the system on.)
There's a lot to say about Secure Boot, and Intel's "measured boot" is rather different from the usual authenticate-then-start approach. If you want to know more, Rutkowska's (of Qubes OS fame) "x86 considered harmful" has quite a lot of good information.
[EDITed to properly spell Rutkowska’s name; thanks, e Erik!]
What exactly are you imagining the maid doing, taking apart the laptop, removing the hard disk, mounting the EFI partition on another device... at that point, why not just install a physical keylogger?
To me, this sort of threat model never made sense, once physical access is possible your main worry ought to be https://xkcd.com/538/
Some people might say they have a detached bootloader (secondary USB which contains the LUKS headers+bootloader), but that depends on them actually keeping the two separate. Even then there is no way to authenticate what you are booting.
Let me introduce you to TPM, signed binaries and measured boot!
However, the most secure ways usually involve a flashed kernel (coreboot) on a write protected NAND chip, of course with encrypted root, that start the boot process by dumping and sha'ing the NAND and comparing that to the whitelist.
On my laptop the SSD can be removed and replaced in 1-2 minutes - you just remove a single panel with 2 screws to get at it. On the other hand, the keyboard would take 10+ minutes to get at and rebuild the computer.
> To me, this sort of threat model never made sense, once physical access is possible your main worry ought to be https://xkcd.com/538/
Sometimes, compromise without the target's knowledge is useful.
Asking for a friend.
https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
The threat model here is a physical attack that either boots an unauthorized operating system or modified the binaries, how useful it is in the real world for most people I don’t know but it can provide some mitigation or at least a detection if someone is trying to mess with your boot sequence hastily like at the airport or overnight at the office.
Basically you can say that if you lose control over the machine it’s not secure anymore which is somewhat true but in reality you can lock down the UEFI effectively enough that without any known vulnerabilities or bypasses even TLA will probably need quite some time to break into it especially without raising any alarms.
The other threat model is that as long as the MoK signing key is not on the machine, any malware that compromises it won’t be able to add persistence in the bootloader layer.
The threat was that users would continue to be able to install other operating systems like Linux or Windows 7 or XP, or multiboot these on brand new PC's no differently than IBM had always intended.
As a universal bootloader, GRUB had always been able to boot Windows just as well as a Windows bootloader, and still could at the time but only if Microsoft SecureBoot was disabled if relying on UEFI.
Windows bootloaders could always also boot Linux under BIOS, but not GPT.
Just in time because Linux was getting more functional than ever, which could lead to actual popularity if left unchecked.
Without further effort on Microsoft's part this has naturally morphed as intended into the significant open-source team effort needed to finally overcome the obstacle just to get back to boot parity on brand-new PC's having default firmware settings.
Along the way looks like multiple revocations will be needed for things other than Windows, but eventually once everything is back on parity again these open-source leaders can dust off their hands and take pride in a job very well done.
Looks like not less than about seven years getting there, this is by design.
Still could be a moving target for a while, but Revocations-R-Us now.
Remember how they said that GPT partitioning had no unaccounted-for sectors like MBR setups always traditionally had between sector 0 and the first sector of the first partition? (these were also one of the optional locations for GRUB to be installed)
Well, they were lying and up until recently using GPT when Microsoft quietly moved their mysterious _Microsoft Reserved_ MSR partition to now be the very first possible one starting at sector 34, there had always been gobs of space, as much but usually much more than under BIOS.
_Traditionaly_, the almost-nonexistent MSR had appeared (geometrically aligned) whether you wanted it or not in between the first usually hidden (boot or EFI) partition, and the first system volume (default C:) on the HDD. Now MSR exists too close to the beginning of the SSD or HDD to geometrically align with erase blocks or 4K sectors. When the concept of all-sectors-allocated is actually achieved, people have still always needed some out-of-partition sectors anyway, whether for GRUB or things like the old _drive overlays_ of BIOS use. So the MSR is there for that reason, but for Microsoft only not for you.
But as always with GPT, sectors 2 through 33 by default still define all your partitions, 4 partitons to a sector. Unless you have more than 8 partitions, sectors 4 through 33 are still blank for everybody no differently than under BIOS.
So much SecureBoot.
I don't know how to say that politely, but you have no idea what you are talking about
With GPT, you can align your partitions on erase block size- align just to 8192 and you'll get an empty 32M that you can use as a partition later. Align more and you will get more space. But you are the one in control, and nothing will "claim" this space if you don't.
Also, it can be done ex post: the MSR can be moved anywhere before the Windows partition (take a binary snapshot then restore it at the new position), and the Windows partition can be resized through Windows itself in a few clicks.
Even better: you can "repair" the installation with some simple commands after booting from a Windows install thumbdrive and letting the Windows Boot Manager installed on the EFI partition know about the new geometry of your system - without even updating the EFI boot entry if you kept the same partition UUID!!
This is something that could be done by free software tools if someone cared enough to reverse the WBM format - so no, nobody is doing anything nefarious there.
You have more freedom and security than even before.
Exactly what I was talking about.
>Also, it can be done ex post: the MSR can be moved anywhere before the Windows partition, and the Windows partition resized through Windows itself.
Can we get a show of hands for how many Windows users have been doing this to their MSR?
No, you were saying that this empty space would be claimed by the MSR, and that it wouldn't work otherwise due to some hostile intent by Microsoft.
So I edited to add that nothing would "claim" this space, as out-of-sequence partitions are not done by OS: the gaps will be left empty.
> Can we get a show of hands for how many Windows users have been doing this to their MSR?
I do, and a lot of people do - because it's technically possible. If you don't know how to, it's your problem, not Microsoft problems.
The modern GPT scheme + UEFI boot as used currently by Windows is extremely permissive yet secure: TPM and MOKs allow signed EFI payloads, and you even got a dedicated EFI partition with lots of free space to put them there! Add a LUKS partition and you're just as secure as Windows Secureboot on Bitlocker.
But you have to learn on how to use these new things, as it's not your grandpa MBR.
I like this well enough to prefer a 32GB FAT32 volume for EFI, so there's enough space for some Live Linux distributions, along with all the boot files I can muster.
I gather that you are quite advanced about the partitioning process, I appreciate it and this is something more people should be aware of.
Under the latest Windows 10 GPT scheme, the MSR by default now extends from sector 34 to the first sector of your system volume, and for performance your system volume is hopefully aligned at a location such as 8192, although 1024 was common for a while. So all these sectors are now well spoken-for.
This is fairly recent and until then sectors 34 through 8191 for instance were being unused by Windows 10, out-of-partition, and unallocated by default. Even though GPT was touted the whole time as having no unallocated sectors by default. These sectors were not being scanned by Windows Defender.
This amounted to significantly more out-of-partition space than most of the 21st century BIOS arrangements, where things like GRUB could mainly rely only on sectors 1 through 62 for bootcode in excess of a single sector (like when GRUB stages were installed right there rather than optionally contained within an actual filesystem).
So now the MSR takes up this space with an actual GPT partition here instead of leaving it fallow like it did originally.
GRUB does not need this space for GPT use since UEFI GRUB is only targeted to boot code in files within a filesystem, like Windows does in its own way too. Windows partitions still have boot sectors but they are not used for booting any more under GPT.
As mentioned, now the only thing generally remaining for potentially malicious or useful out-of-partition hacking on GPT is in about the sector 4 to 33 range, even though these are already taken and have always been spoken for by design, virtually nobody has anything but zeros there.
>But you have to learn on how to use these new things, as it's not your grandpa MBR.
Mainly only Linux users who want to get equivalent boot performance compared to MBR systems.
Revocation of previous Microsoft-signed Linux keys (just as they were becoming viable) was looming but now really here, so since after 2019 additional mastery even further beyond that required by Windows is needed just to achieve or maintain parity, eventually.
Which I was wrong about, it's actually been about 9 years of hostility so far.
Take a look at what might be happening/proposed with SYSTEMD for booting and with the proper input plus great care a new Linux bootloader could arise to overcome remaining obstacles. This needs to really be jumped on before it has a chance to become misguided. There simply needs to be a single Microsoft-signed bootloader that can boot any Linux, or Windows, from a user-configurable menu.
Along these lines a focused amount of work needs to be done with UEFI Shell programs, and that might be all it requires.
Obviously Microsoft could have provided this long ago or incorporate it into their current routine if they had a truly non-hostile approach to open-source.
So it looks like Microsoft is still lying at least about one of the most important things.
Great idea, so it's always there when you need it!
> Under the latest Windows 10 GPT scheme, the MSR by default now extends from sector 34 to the first sector of your system volume, and for performance your system volume is hopefully aligned at a location such as 8192, although 1024 was common for a while. So all these sectors are now well spoken-for. This is fairly recent and until then sectors 34 through 8191 for instance were being unused by Windows 10, out-of-partition, and unallocated by default.
It must be very recent because it never happened to me. If it did, I would just move the MSR. I guess Microsoft is just trying to use the leftovers to be less intrusive? But with a large enough EFI, I don't really care.
> Revocation of previous Microsoft-signed Linux keys
Use your own keys! Don't depend on someone else's keys!
> Take a look at what might be happening/proposed with SYSTEMD for booting and with the proper input plus great care a new Linux bootloader could arise to overcome remaining obstacles
It has already happened: I follow the Arch way of a "fat" EFI payload using systemd EFI stuff: so I have a kernel + initrd (+ cmdline) in one EFI file - and no need for a bootloader anymore, as the UEFI can directly boot this EFI payload.
Sign this file with your own keys (MOK) and you're king of your castle
> There simply needs to be a single Microsoft-signed bootloader that can boot any Linux, or Windows, from a user-configurable menu
A menu is a waste of time. I keep my EFI payload on the EFI partition. I never need to change the kernel cmdline. One less piece of software (a good thing as grub2 had recent vulnerabilities)
> Along these lines a focused amount of work needs to be done with UEFI Shell programs, and that might be all it requires
There are a few good ones, that can help you in case of problems - but booting a live distribution is almost faster. Your idea of keeping it right in the EFI partition is great - we simply need to change our habits and create larger EFI partitions. It's the ideal place to put it, as Windows or anything else won't dare touch it there.
> So it looks like Microsoft is still lying at least about one of the most important things.
Maybe - but we don't really need them with MOK keys and the systemd EFI stub.
The TPM can be used to verify that the next boot stage has not been compromised, but it cannot do the first step, so if bad code inserts itself right up front it can lie to the TPM and unlock the security keys under malware control.
> GRUB2 enables the use of the command acpi even when Secure Boot is signaled by the firmware. An attacker with local root privileges to can drop a small SSDT in /boot/efi and modify grub.cfg
Oh the horror of being allowed to modify your own fucking computer.
If your Grandpa even had a computer decades ago, at least there was one less reason to expletively delete.
This seems like exactly what Microsoft would want to inhibit flexibility.
I think it's still more elegant for GRUB to be a _universal_ boot loader as originally intended.
Also worth waiting for SYSLINUX to allow all this nonsense to be overcome.
Is something pending with SYSLINUX?
Try to make it revocation-proof as much as Windows.
Until then make the best use of GRUB2 that you can.
I'm not trying to win a popularity contest, but it doesn't look like just anyone would be able to make the kind of worthwhile contribution that would be helpful.
To anyone having nothing positive to offer, I can also recommend refraining from joining the mailing list in this case.