Kwetsbaarheden van GRUB2 UEFI SecureBoot - 2021

Sinds de groep van "BootHole"-bugs in GRUB2 die in juli 2020 werden bekendgemaakt, zijn beveiligingsonderzoekers en ontwikkelaars in Debian en elders blijven zoeken naar nog andere problemen die het mogelijk zouden maken om UEFI Secure Boot (UEFI veilige opstart) te omzeilen. Er werden er verschillende gevonden. Zie het Debian Beveiligingsadvies 4867-1 voor meer volledige informatie. Het doel van dit document is om de gevolgen van deze kwetsbaarheid op het gebied van beveiliging uit te leggen en toe te lichten welke stappen ondernomen werden om deze aan te pakken.

Achtergrond: Wat is UEFI Secure Boot?

UEFI Secure Boot (SB - UEFI veilige opstart) is een verificatiemechanisme dat moet verzekeren dat de code die door de UEFI firmware van een computer gelanceerd wordt, te vertrouwen is. Het is ontworpen om het systeem te beschermen tegen het laden en uitvoeren van kwaadaardige code vroegtijdig in het opstartproces, nog voordat het besturingssysteem geladen wordt.

SB werkt met cryptografische controlegetallen en handtekeningen. Elk programma dat door de firmware geladen wordt heeft een handtekening en een controlegetal en voordat de uitvoering van het programma toegestaan wordt, zal de firmware nagaan of het betrouwbaar is door de geldigheid van het controlegetal en de handtekening te controleren. Wanneer SB op het systeem geactiveerd is, zal een poging om een onbetrouwbaar programma uit te voeren niet toegestaan worden. Dit voorkomt het uitvoeren van onverwachte/ongeoorloofde code in een UEFI-omgeving.

De meeste x86-hardware wordt door de fabrikant geleverd met Microsoft-sleutels. Dit betekent dat de firmware op deze systemen binaire code zal vertrouwen die ondertekend werd door Microsoft. De meeste moderne systemen worden geleverd met een geactiveerd SB-systeem - standaard zullen zij geen niet-ondertekende code uitvoeren, maar het is mogelijk om de firmware-configuratie aan te passen om SB uit te schakelen of om extra ondertekeningssleutels op te nemen.

Zoals veel op Linux gebaseerde besturingssystemen, gebruikt Debian het programma shim om dat vertrouwen van de firmware uit te breiden naar de andere programma's die beveiligd moeten worden tijdens de vroege stadia van het opstartproces: de GRUB2-bootloader, de Linux-kernel en hulpmiddelen voor het opwaarderen van firmware (fwupd en fwupdate).

Meerdere bugs aangetroffen in GRUB2

Er werd een bug aangetroffen in de module acpi van GRUB2. Deze module is ontworpen om een stuurprogramma-interface te bieden voor ACPI ("Advanced Configuration and Power Interface" - Geavanceerde configuratie en elektrische voedingsinterface), een gebruikelijk onderdeel van moderne computerhardware. Helaas staat de ACPI-module momenteel ook een bevoorrechte gebruiker toe om vervaardigde ACPI-tabellen onder Secure Boot te laden en willekeurige wijzigingen in de systeemstatus aan te brengen; hierdoor kunnen mensen gemakkelijk de Secure Boot-keten doorbreken. Dit beveiligingslek is nu verholpen.

Zoals dit het geval was met BootHole, hebben ontwikkelaars in plaats van enkel deze ene bug te repareren een diepgaande audit en analyse van de broncode van GRUB2 uitgevoerd. Het ware onverantwoord geweest om enkel één belangrijk probleem op te lossen zonder ook op zoek te gaan naar mogelijke andere problemen. We hebben een paar andere plaatsen gevonden waar interne geheugentoewijzingen kunnen overlopen bij onverwachte invoer en enkele plaatsen waar geheugen kan worden gebruikt nadat het is vrijgegeven. Oplossingen voor al deze problemen werden binnen de gemeenschap uitgewisseld en getest.

Nogmaals, zie het Debian Beveiligingsadvies 4867-1 voor een volledige lijst van gevonden problemen.

Er moeten sleutels ingetrokken worden om de Secure-Boot-keten te repareren

Debian en andere leveranciers van besturingssystemen zullen ongetwijfeld gerepareerde versies uitbrengen van GRUB2. Dit houdt echter geen volledige reparatie in van de hier gesignaleerde problemen. Kwaadwillige personen zouden nog steeds gebruik kunnen maken van oudere kwetsbare versies van GRUB2 om Secure Boot te omzeilen.

Om dat te stoppen, is de volgende stap dat Microsoft die onveilige binaire bestanden blokkeert om te voorkomen dat ze onder SB worden uitgevoerd. Dit is mogelijk via de DBX-lijst, een functionaliteit van het UEFI Secure Boot-ontwerp. Aan alle Linux-distributies die door Microsoft ondertekende versies van shim bevatten, werd gevraagd details over te maken van de betreffende programma's en sleutels om dit proces te faciliteren. Het bestand met de lijst van UEFI-intrekkingen zal bijgewerkt worden om deze informatie op te nemen. Op een bepaald moment in de toekomst zullen systemen deze bijgewerkte lijst beginnen gebruiken en weigeren de kwetsbare programma's nog langer onder Secure Boot uit te voeren.

De exacte tijdlijn voor het ontplooien van deze aanpassingen is nog niet bekend. Ergens in de toekomst zullen BIOS/UEFI-leveranciers deze nieuwe lijst met intrekkingen beginnen gebruiken in recentere firmware-versies voor nieuwe hardware. Mogelijk zal ook Microsoft updates uitbrengen voor bestaande systemen via Windows Update. Mogelijk zullen bepaalde Linux-distributies updates uitbrengen via hun eigen proces van beveiligingsupdates. Momenteel doet Debian dat nog niet, maar we bekijken het voor de toekomst.

Welke effecten heeft het intrekken van de sleutels?

De meeste leveranciers wantrouwen het automatisch toepassen van updates die sleutels intrekken die voor Secure Boot worden gebruikt. Voor SB geschikt gemaakte bestaande software-installaties zouden mogelijk plots helemaal niet meer kunnen opstarten, tenzij de gebruiker er zorg voor gedragen heeft om ook alle nodige software-updates te installeren. Windows/Linux dual-bootsystemen zouden plots niet meer in staat kunnen zijn om Linux op te starten. Ook oude installaties en live-systemen zouden natuurlijk niet langer kunnen opstarten, wat het potentieel moeilijker zou maken om systemen te herstellen.

Er zijn twee voor de hand liggende manieren om een dergelijk niet-opstartend systeem te repareren:

Beide mogelijkheden kunnen eenvoudig lijken, maar allebei kunnen ze tijdrovend zijn voor gebruikers die verschillende systemen moeten onderhouden. Houd er ook rekening mee dat het in- of uitschakelen van Secure Boot standaard directe toegang tot de machine vereist. Normaal is het onmogelijk om deze configuratie aan te passen buiten het instellingenprogramma van de firmware om. Net om deze reden dient men mogelijk extra zorg te besteden aan servercomputers die op een andere locatie staan.

Om deze redenen wordt alle Debian-gebruikers ten zeerste aanbevolen ervoor te zorgen dat alle aanbevolen updates zo snel mogelijk op hun systeem geïnstalleerd worden om de kans op problemen in de toekomst te verkleinen.

Bijgewerkte pakketten en sleutels

Opmerking: Systemen met Debian 9 (stretch) of ouder zullen hier niet noodzakelijk updates krijgen, omdat Debian 10 (buster) de eerste release van Debian was met ingebouwde ondersteuning voor UEFI Secure Boot.

Er zijn vijf broncodepakketten in Debian die zullen worden bijgewerkt vanwege de hier beschreven UEFI Secure Boot-wijzigingen:

1. GRUB2

Bijgewerkte versies van de GRUB2-pakketten van Debian zijn nu beschikbaar via het archief debian-security van de stabiele release Debian 10 (buster). Zeer binnenkort zullen gerepareerde versies voor de ontwikkelingsversies van Debian (unstable en testing) beschikbaar zijn in het normale Debian archief.

2. Linux

Bijgewerkte versies van de linux-pakketten van Debian zullen binnenkort beschikbaar zijn via het archief buster-proposed-updates van de stabiele release Debian 10 (buster) en zullen worden opgenomen in de komende tussenrelease 10.10. Ook in het Debian-archief voor de ontwikkelingsversies van Debian (unstable en testing) zullen binnenkort nieuwe pakketten aanwezig zijn. We hopen tevens binnenkort gerepareerde pakketten te kunnen uploaden naar buster-backports.

3. Shim en SBAT

Met de reeks "BootHole"-bugs was het de eerste keer dat er op grote schaal sleutels moesten worden ingetrokken in het UEFI Secure Boot-ecosysteem. Het toonde een ongelukkige ontwerpfout in de intrekking van SB-sleutels: met veel verschillende Linux-distributies en veel UEFI-binaire bestanden, groeit de omvang van de intrekkingslijst snel. Veel computersystemen hebben slechts een beperkte hoeveelheid ruimte voor het opslaan van gegevens over het intrekken van sleutels, en die zou snel kunnen vollopen en dat systeem op verschillende manieren onbruikbaar kunnen maken.

Om dit probleem aan te pakken, hebben de ontwikkelaars van shim een methode bedacht om in de toekomst onveilige UEFI binaire bestanden te blokkeren die veel meer ruimtebesparend is. Deze methode heet SBAT (Secure Boot Advanced Targeting - Secure Boot geavanceerde doelgerichtheid). Ze werkt door het bijhouden van generatienummers van ondertekende programma's. In plaats van handtekeningen afzonderlijk in te trekken als er problemen worden gevonden, worden tellers gebruikt om aan te geven dat oude versies van programma's niet langer als veilig worden beschouwd. Het intrekken van een oude serie van GRUB2 binaire bestanden (bijvoorbeeld) wordt nu een geval van het bijwerken van een UEFI-variabele die het generatienummer voor GRUB2 bevat; alle versies van GRUB2-software die ouder zijn dan dat nummer zullen niet langer als veilig worden beschouwd. Voor veel meer informatie over SBAT, zie de SBAT-documentatie van shim.

Helaas is deze nieuwe SBAT-ontwikkeling voor shim nog niet helemaal klaar. Ontwikkelaars waren van plan om nu een nieuwe versie van shim uit te brengen met deze belangrijke nieuwe functie, maar stuitten op onverwachte problemen. De ontwikkeling is nog steeds aan de gang. In de hele Linux-gemeenschap verwachten we zeer binnenkort naar deze nieuwe versie van shim te kunnen updaten. Totdat die klaar is, zullen we allemaal onze bestaande ondertekende binaire bestanden van shim blijven gebruiken.

Bijgewerkte versies van Debian's shim-pakketten zullen beschikbaar worden gesteld zodra dit werk is voltooid. Ze zullen hier en elders worden aangekondigd. We zullen op dat moment een nieuwe tussenrelease 10.10 publiceren, en ook nieuwe shim-pakketten uitbrengen voor de ontwikkelingsversies van Debian (unstable en testing).

4. Fwupdate

Bijgewerkte versies van de fwupdate-pakketten van Debian zullen binnenkort via buster-proposed-updates beschikbaar zijn voor de stabiele release Debian 10 (buster) en deze zullen opgenomen worden in de komende tussenrelease 10.10. Reeds een tijd geleden werd fwupdate verwijderd uit unstable en testing ten gunste van fwupd.

5. Fwupd

Bijgewerkte versies van de fwupd-pakketten van Debian zullen binnenkort via buster-proposed-updates beschikbaar zijn voor de stabiele release Debian 10 (buster) en deze zullen opgenomen worden in de komende tussenrelease 10.10. Er zijn ook nieuwe pakketten in het archief van Debian voor de ontwikkelingsversies van Debian (unstable en testing).

6. Sleutels

Debian heeft nieuwe ondertekeningssleutels en certificaten gegenereerd voor zijn Secure Boot-pakketten. Vroeger gebruikten we één certificaat voor al onze pakketten:

Wij zijn nu overgeschakeld op het gebruik van afzonderlijke sleutels en certificaten voor elk van de vijf verschillende broncodepakketten, om in de toekomst meer flexibiliteit te hebben:

Tussenrelease Debian 10.10 (buster), bijgewerkte installatie- en live-media

Het is de bedoeling dat alle hier beschreven oplossingen opgenomen worden in de tussenrelease Debian 10.10 (buster), welke voor binnenkort voorzien is. Om die reden zal 10.10 een goede keuze zijn voor gebruikers die op zoek zijn naar Debian installatie- en live-media. Het is mogelijk dat eerdere versies niet langer zullen werken met Secure Boot wanneer de intrekkingen van de sleutels uitgevoerd worden.

Meer informatie

Veel meer informatie over hoe UEFI Secure Boot opgezet is in Debian, is te vinden in de wiki-pagina's van Debian - zie https://wiki.debian.org/SecureBoot.

Andere informatiebronnen over dit onderwerp zijn onder meer: