Ubuntu-ontwikkelaars willen Grub terugbrengen tot de essentiële functies

De Ubuntu-ontwikkelaars zijn van plan om de functionaliteit van de bootloader Grub in te perken: geen grafische weergave meer, geen LVM, geen RAID, geen Btrfs. Dat moet het aantal aanvalsmogelijkheden verminderen.

Meer veiligheid door minder code: dat is het simpele principe achter het plan van de Ubuntu-ontwikkelaars om vanaf Ubuntu 26.10 een flink aantal functies uit de Grub-bootloader te verwijderen. Op de lijst van te schrappen onderdelen staan de ondersteuning van diverse bestandssystemen, maar ook de Logical Volume Manager (LVM), RAID en de integratie van grafische weergave.

De meeste Ubuntu-gebruikers zullen daar helemaal niets van merken, want de distributie maakt helemaal geen gebruik van de functies die op die lijst staan. Maar omdat Ubuntu ook als basis dient voor verschillende afgeleide versies (flavours), ontstaat er bij die ontwikkelaars weerstand tegen sommige onderdelen op de schraplijst.

Om de beweegredenen van die ontwikkelaars te begrijpen en de gevolgen te kunnen inschatten, moet je snappen welke belangrijke rol Grub speelt bij Secure Boot. Grub is niet zomaar een programma dat draait in een door de kernel gecontroleerd en beveiligd geheugengebied en alleen de rechten heeft van de gebruiker die het start.

Als bootloader is Grub een belangrijk onderdeel van de beveiligingsarchitectuur van Secure Boot: als een aanvaller erin slaagt Grub te compromitteren, kan hij in het ergste geval achterdeurtjes openen, de kernel virtualiseren en het geheugen manipuleren – waardoor hij uiteindelijk de controle over het hele systeem, inclusief alle applicaties, kan overnemen.

Fouten in Grub brengen de betrouwbaarheid van de Secure Boot-keten in gevaar.

Het idee achter Secure Boot is dat een computer alleen betrouwbare besturingssystemen opstart. Daarvoor zijn in het BIOS van de computer fabrieksmatig certificaten van Microsoft opgeslagen waarmee de Windows-bootloader van Microsoft ondertekend is. Voordat het UEFI-BIOS de bootloader opstart, controleert het de handtekening ervan.

Om Linux op te starten, moet ook de bootloader daarvan ondertekend zijn. Aangezien er meestal alleen het Microsoft-certificaat in het BIOS van een computer zit, heeft elke Linux-versie ook een handtekening van Microsoft nodig als hij op een gewone pc met Secure Boot moet opstarten.

Microsoft krijgt echter niet Grub ter ondertekening voorgelegd, maar de bijzonder minimalistische bootloader Shim, ook wel de First Stage Loader genoemd. De certificering is namelijk erg omslachtig – en je zou Grub na elke nog zo kleine wijziging opnieuw moeten indienen.

Shim kan daarentegen bijna niets: hij laadt een andere bootloader via de UEFI-functies van het BIOS en laat die vervolgens, eveneens via de UEFI-firmware, opstarten. Als dat niet lukt, laadt Shim zelf de bootloader, controleert die en voert hem uit. Dat is alles.

Als Shim de UEFI-functies LoadImage() en StartImage() gebruikt, controleert het UEFI-BIOS of de doorgegeven bootloader ondertekend is met een geldig (Microsoft-)certificaat en niet op de ingebouwde blacklist (DBX) staat. Daarna start het die op.

Lukt dat niet, bijvoorbeeld omdat de te laden bootloader niet door Microsoft ondertekend is, dan laadt Shim de bootloader zelf – en controleert of het de handtekening kan vergelijken met een certificaat uit een eigen, in Shim geïntegreerde lijst. Zo ja, dan start Shim de bootloader op.

Die zeer beperkte functionaliteit betekent ook dat er maar zelden wijzigingen in de broncode van Shim nodig zijn en dus ook maar zelden hercertificeringen door Microsoft. Door Shim te voorzien van een eigen lijst met certificaten, voorkomen de distributeurs dat ze de veel complexere bootloader Grub na elke wijziging opnieuw bij Microsoft moeten indienen.

In plaats daarvan ondertekenen ze Grub na elke update zelf met het certificaat van de distributeur dat in Shim opgeslagen is. Omdat Shim, inclusief de certificaten van de distributeurs, door Microsoft is ondertekend en op zijn beurt alleen bootloaders start die met het certificaat van de distributeur zijn ondertekend, blijft de betrouwbaarheid van het opstartproces gewaarborgd.

Een aanvaller kan Grub daarom niet zomaar vervangen door een eigen, gecompromitteerde variant – hij beschikt immers niet over de certificaten van Microsoft of Canonical om zijn bootloader correct te ondertekenen. Voor een succesvolle aanval moet hij daarom kwetsbaarheden vinden in de Grub-implementatie van de distributeur.

Daarbij profiteert hij van de uitgebreide functionaliteit van die bootloader. Meer code, meer kwetsbaarheden Zo ondersteunt Grub meerdere partitietypen, bijna een dozijn bestandssystemen, heeft het een grafische modus en kan het zelfs afbeeldingen en logo’s in het opstartmenu weergeven.

En natuurlijk hebben de Grub-ontwikkelaars de daarvoor benodigde functies, bijvoorbeeld om een PNG- of JPG-afbeelding te laden, niet zelf geschreven, maar maken ze gebruik van geschikte standaardbibliotheken zoals libpng en libjpeg. Dat is een goed idee, want de bootloader-ontwikkelaars zijn niet per se ook grafische of bestandssysteemspecialisten.

Maar met elke functie en elke bibliotheek neemt de complexiteit van het programma toe. Daardoor stijgt ook de kans dat aanvallers een kwetsbaarheid vinden. Met door AI gestuurde vibe-hacking is dat gevaar vandaag de dag groter dan ooit tevoren. Vooral functies die niet-geverifieerde gegevens laden – bijvoorbeeld een achtergrondafbeelding – zijn daarbij kwetsbaar. Terwijl een aanvaller Grub niet kan vervangen door een gemanipuleerde variant vanwege de handtekening die nodig is voor Secure Boot, is dat bij een achtergrondafbeelding daarentegen zonder problemen mogelijk.

Ook het Grub-configuratiebestand is toegankelijk voor een lokale aanvaller, hij kan dat zodanig aanpassen dat de afbeelding bij het opstarten geladen wordt. Dan moet hij alleen nog een afbeeldingsbestand zo manipuleren dat het misbruik maakt van een bug in de grafische bibliotheek om eigen code uit te voeren – en voilà, de aanvaller heeft de controle over de computer overgenomen, ook al meldt Secure Boot via de UEFI-functies nog steeds onbeperkte betrouwbaarheid.

Een gemanipuleerde afbeelding die code uitvoert tijdens het laden? Wat klinkt als een nogal bizarre aanpak, komt toch steeds weer voor. Zo’n kwetsbaarheid wordt bijvoorbeeld beschreven in CVE-2026-33416. Gelukkig was Grub daar niet door getroffen, maar daar is geen garantie voor.

In het verleden zijn er alleen al in de grafische bibliotheken libpng en libjpeg talloze geheugenoverloopfouten gevonden, waarvan sommige het mogelijk maakten om code via afbeeldingen binnen te smokkelen. Als je kijkt naar de bekend geworden beveiligingslekken in de door Grub ondersteunde bestandssystemen van de afgelopen jaren – die een lokale aanvaller ook makkelijk kan manipuleren en misbruiken – dan ontstaat er een behoorlijk dreigingsscenario.

Een schoolvoorbeeld van hoe een ogenschijnlijk onschuldige bibliotheek een ernstig beveiligingslek in applicaties kan veroorzaken, is de Log4Shell-zaak [1]. De Java-bibliotheek log4j is een Zwitsers zakmes voor logbestanden en alle andere vormen van logboeken, tot en met debugging-informatie.

Er is bijna geen enkel Java-programma dat geen gebruik maakt van log4j: het is volwassen, al jarenlang beproefd en universeel inzetbaar, van een programmaatje van tien regels tot een enterprise-app met miljoenen regels code.

Té universeel, zo bleek in december 2021. Blijkbaar was bijna niemand zich ervan bewust dat log4j via een zelden gebruikte aanroep van een andere bibliotheek heel gewoon code van het internet kon downloaden en uitvoeren.

De Ubuntu-ontwikkelaars willen dergelijke verrassingen voorkomen door Grub terug te brengen tot precies die functies die een Ubuntu-bootloader nodig heeft. Zo gebruikt Ubuntu geen achtergrondafbeelding in de bootloader, en daarom is het plan om dat deel uit te schakelen en daarmee de grafische bibliotheken te vermijden. Dat verkleint direct het aanvalsoppervlak.

Ook bij de bestandssystemen wil men bezuinigen: in de toekomst moet Grub alleen nog opstartpartities met Ext4, FAT, ISO9660 en SquashFS ondersteunen. Omdat de aanbevolen (UEFI-)installatie van Ubuntu altijd voorziet in een EFI-partitie in FAT-formaat en een opstartpartitie met het Ext4-bestandssysteem, heb je in Grub Btrfs, ZFS en XFS niet nodig.

Om ervoor te zorgen dat ook USB-sticks en DVD-images kunnen opstarten, wil men bovendien ISO9660 en SquashFS behouden als beschrijfbare overlay. Het root-bestandssysteem heeft geen last van die beperkingen, want dat wordt pas gemount door de kernel die op de opstartpartitie staat.

Ook de ondersteuning voor software-RAID’s (behalve RAID 1), versleutelde opstartpartities en opstartpartities op LVM-schijven willen de Ubuntu-ontwikkelaars verwijderen. Want dat is allemaal niet bedoeld voor de opstartpartitie in Ubuntu, ook al is dat momenteel technisch mogelijk. De huidige functionaliteit van Ubuntu’s Grub is namelijk gebaseerd op die van Debian, waar Ubuntu zijn roots heeft.

De belangen van de officiële Ubuntu-varianten zoals Kubuntu of Xubuntu spelen in de huidige discussie geen wezenlijke rol. Er wordt vooral gevraagd om de Btrfs-ondersteuning te behouden vanwege de populariteit van dat bestandssysteem. Het valt nog te bezien of de Ubuntu-ontwikkelaars daar misschien een uitzondering maken en niet alleen de absoluut noodzakelijke functies behouden.

Met het plan om Grub te stroomlijnen, volgen de Ubuntu-ontwikkelaars dezelfde aanpak die al leidde tot de ontwikkeling van Shim: keep it small and simple. Dat verkleint het aanvalsoppervlak van Grub, maar de grote problemen van Secure Boot liggen heel ergens anders: het duurt maanden, soms zelfs vele maanden, voordat een kwetsbare bootloader door Microsoft op de zwarte lijst wordt gezet en die via de reguliere updates van het betreffende besturingssysteem in het UEFI-BIOS van de computer terechtkomt.

Microsoft raakt die lastige klus ook maar moeilijk kwijt: enerzijds is Microsoft altijd de zondebok als Linux-distributies weer eens niet opstarten vanwege updates van de zwarte lijst – daarom krijgen ze de tijd om nieuwe bootloaders uit te brengen.

Anderzijds kunnen die updates eigenlijk niet snel genoeg gaan om het concept van Secure Boot niet blijvend te schaden. Wat ze bij Microsoft ook doen, uiteindelijk is er altijd wel iemand die er niet blij mee is. Door ontwerpfouten in de standaard is het bovendien niet zeker of de inmiddels talrijke vermeldingen überhaupt wel in de beperkte opslagruimte van de blacklist passen.

Ook is het niet zeker of een computer over alle gepubliceerde blacklist-vermeldingen beschikt, want sommige vermeldingen worden samen met het UEFI-BIOS meegeleverd. Als je de fabrieksinstellingen van het BIOS laadt, worden later geïnstalleerde blacklists gewist.

Het is dus praktisch onmogelijk om erachter te komen of de bootloader-blacklist van Secure Boot op een specifieke computer wel compleet is, of dat er toch een bekend onveilige, oudere bootloader zou opstarten. Omdat het bovendien best lang duurt voordat een bootloader op de blacklist terechtkomt, hoeft een aanvaller eigenlijk alleen maar de bekend geworden beveiligingsproblemen van de afgelopen maanden door te nemen om een kwetsbare bootloader te vinden die ondanks ingeschakelde Secure Boot toch opstart – om die vervolgens te kraken.

Om de bestaande Grub te vervangen door een oudere, kwetsbare variant, moet de aanvaller echter toegang krijgen tot het bestandssysteem van de opstartpartitie. Mogelijk is ook een downgrade van Shim op de EFI-partitie nodig. Daar heeft een aanvaller root-rechten op een draaiend systeem voor nodig – waardoor het manipuleren van de bootloader eigenlijk overbodig wordt – of fysieke toegang tot de computer.

Maar er is een lichtpuntje: sinds een paar maanden vernieuwt Microsoft zijn certificaten regelmatig. De UEFI-certificaten voor Windows en andere aanbieders, zoals Linux-distributeurs, lopen namelijk nog voor het einde van het jaar af en kunnen straks niet meer worden gebruikt om nieuwe bootloaders te ondertekenen.

De nieuwe certificaten, die in 2023 zijn aangemaakt, worden via Windows-updates aan de bestaande toegevoegd. Daardoor start de computer zowel de oude bootloaders op die met de oude certificaten zijn ondertekend, als toekomstige bootloaders die dan de handtekening van een van de drie nieuwe certificaten dragen.

Die overgangsfase duurt niet eeuwig: Microsoft is van plan om in de toekomst via een volgende update de oude certificaten op de zwarte lijst te zetten. Daardoor worden in één klap ook alle oude bootloaders uitgeschakeld, zijn individuele blacklist-vermeldingen voor oude bootloaders niet meer nodig en is er weer ruimte voor nieuwe blacklist-vermeldingen.

Slecht nieuws voor aanvallers, want dan moeten ze in een relatief nieuwe Grub een ernstig beveiligingslek vinden dat ze kunnen misbruiken. Bij een tot het hoogstnodige teruggebrachte Grub, zoals de ontwikkelaars dat momenteel voor Ubuntu 26.10 voor ogen hebben, zal dat behoorlijk lastig worden.

[1] Mirko Dölle en Daniel Dupré, Log4Sshell beveiligingslek, Brandhaard op internet, c’t 3/2022, p.10

Mirko Dölle en Noud van Kruysbergen