image

Boothole-lek in Grub2-bootloader laat aanvaller code uitvoeren tijdens bootproces

donderdag 30 juli 2020, 09:57 door Redactie, 19 reacties

Een kwetsbaarheid in de Grub2-bootloader, die wordt gebruikt voor het laden van het besturingssysteem, maakt het mogelijk voor een aanvaller met fysieke toegang of beheerdersrechten om willekeurige code uit te voeren voordat het besturingssysteem wordt geladen, zelfs wanneer Secure Boot is ingeschakeld. Daarvoor waarschuwt securitybedrijf Eclypsium dat het probleem ontdekte.

Secure Boot werd in 2012 door Microsoft geïntroduceerd als maatregel om rootkits tegen te gaan. Via dit mechanisme wordt gecontroleerd dat de code die de firmware van de computer laadt te vertrouwen is. Secure Boot doet dit door de digitale handtekening van een bestand te controleren voordat het geladen wordt. Om van Secure Boot gebruik te kunnen maken signeert Microsoft de bootcode voor zowel Windows als derde partijen, waaronder Linux-distributies. Zo kunnen ook Linux-systemen van Secure Boot gebruikmaken.

Grub2 (GRand Unified Boot Loader) is de standaard bootloader voor nagenoeg alle Linux-distributies. Het probleem raakt echter niet alleen systemen die via Grub2 opstarten. Alle systemen die via Secure Boot werken lopen risico, zo stelt Eclypsium. Het beveiligingslek, dat de naam BootHole heeft gekregen, raakt dan ook bijna alle Linuxcomputers, alsmede Windowscomputers die van Secure Boot gebruikmaken en de standaard Microsoft Third Party UEFI Certificate Authority vertrouwen.

De kwetsbaarheid wordt veroorzaakt door de manier waarop Grub2 het configuratiebestand grub.cfg verwerkt. Dit bestand is niet digitaal gesigneerd en wordt zodoende niet door Secure Boot gecontroleerd. Door dit bestand aan te passen kan een aanvaller een buffer overflow binnen Grub2 veroorzaken en zo willekeurige bootcode aanpassen. Vervolgens is het mogelijk om verdere controle van te laden bestanden, zoals drivers en uitvoerbare bestanden, uit te schakelen. Secure Boot zal deze bestanden niet controleren, terwijl ze wel voor het opstarten van het besturingssysteem worden geladen.

Zodoende kan de aanvaller bepalen hoe het besturingssysteem wordt geladen, het besturingssysteem aanpassen of de bootloader een ander besturingssysteem-image laten laden. Een aanvaller kan zo bijvoorbeeld een rootkit installeren en volledige controle over het systeem krijgen. Alle Grub2-versies die commando's van een extern grub.cfg bestand laden zijn kwetsbaar, aldus het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit. Om de aanval uit te voeren moet een aanvaller beheerdersrechten of fysieke toegang hebben.

Eclypsium waarschuwt dat onder andere Microsoft, Oracle, Red Hat, Canonical, SuSE, HP, HPE, Debian, Citrix en VMware door de kwetsbaarheid zijn getroffen. Beheerders en gebruikers wordt aangeraden om naar de laatste versie van Grub2 te updaten, aangezien het probleem daar is verholpen. Linuxdistributies en andere leveranciers die Grub2 gebruiken zullen hun installers, bootloaders en shims, een digitaal gesigneerd programma dat het certificaat van de leverancier en code bevat die de bootloader verifieert en laadt, moeten updaten, aldus het CERT/CC.

Beheerders zullen naast het updaten van besturingssystemen ook hun installer-images en disaster recovery media moeten patchen. Microsoft werkt aan een Windows-update. Beheerders die het probleem meteen willen verhelpen kunnen een mitigatie doorvoeren of een nog niet geteste update installeren. Andere partijen hebben al updates uitgebracht of zullen daar nog mee komen.

Image

Reacties (19)
30-07-2020, 10:48 door Anoniem
Ik weet niet of ik dit echt interessant vind.
Het is weer zo'n fout dat iemand fysieke toegang tot je systeem heeft. Dat is denk ik de eerste en doorslaggevende fout: laat geen onbevoegden bij je systeem.
Is er wel een onbevoegde zonder toezicht bij je systeem geweest, dan vind ik persoonlijk het systeem al gecompromiteerd.
30-07-2020, 11:14 door souplost - Bijgewerkt: 30-07-2020, 11:15
Zodoende kan de aanvaller bepalen hoe het besturingssysteem wordt geladen, het besturingssysteem aanpassen of de bootloader een ander besturingssysteem-image laten laden
De kop doet het ergste vermoeden maar er is 1 probleem.
Een mogelijke aanvaller zal eerst (fysieke) toegang tot het systeem moeten krijgen (dan heb je al de macht over het systeem) of de mogelijkheid moeten hebben om een pxe-boot-netwerk te wijzigen. Daar zullen dus niet veel beheerders wakker van liggen.
Microsoft werkt aan een Windows-update lees ik, maar die zal niet kritiek zijn.
30-07-2020, 11:30 door Anoniem
Geen boothole lek in GRUB aangezien het ook in Windows een probleem is. Vreemde misleidende titel. Het enige dat het noemen van Linux en/of GRUB rechtvaardigt is het feit dat deze kwestbaarheid als eerste gevonden is in Linux.
30-07-2020, 11:40 door Anoniem
Het probleem is dat iedere aanvaller nu een Grub2 programma in de bootsector van elke harddisk kan plaatsen. En daarmee Secure Boot volledig kan omzeilen. De aanvaller krijgt dan dezelfde rechten als Grub2. Root dus.

Omdat Grub2 digitaal ondertekend is, moeten alle UEFI biossen geupdated worden zodat ze deze sleutel niet meer gebruiken. Deze sleutel moet in alle UEFI biossen worden ingetrokken.

Of Secure Boot een goed idee van Microsoft was is iets anders. Maar Microsoft heeft wel meer stomme ideeën (zoals autorun.inf, het standaard verbergen van bestandstypes en Macro's in tekst documenten).
30-07-2020, 12:20 door Anoniem
Door Anoniem: Geen boothole lek in GRUB aangezien het ook in Windows een probleem is. Vreemde misleidende titel. Het enige dat het noemen van Linux en/of GRUB rechtvaardigt is het feit dat deze kwestbaarheid als eerste gevonden is in Linux.

Misschien wil je je eerst even inlezen voordat je zomaar wat dingen zegt die niet kloppen...

"BootHole” vulnerability in the GRUB2 bootloader"
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

"GRUB2 bootloader is vulnerable to buffer overflow"
https://kb.cert.org/vuls/id/174059

"GRUB2 UEFI SecureBoot vulnerability"
https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/
30-07-2020, 12:30 door Anoniem
Door Anoniem: Geen boothole lek in GRUB aangezien het ook in Windows een probleem is. Vreemde misleidende titel. Het enige dat het noemen van Linux en/of GRUB rechtvaardigt is het feit dat deze kwestbaarheid als eerste gevonden is in Linux.
Het is wel degelijk een GRUB lek, dat staat zelfs letterlijk in de tweede zin in het bronartikel:

All operating systems using GRUB2 with Secure Boot must release new installers and bootloaders.

Met vervolgens de lijst met mitigerende maatregelen:

1. Updates to GRUB2 to address the vulnerability.
2. Linux distributions and other vendors using GRUB2 will need to update their installers, bootloaders, and shims.
3. New shims will need to be signed by the Microsoft 3rd Party UEFI CA.
4. Administrators of affected devices will need to update installed versions of operating systems in the field as well as installer images, including disaster recovery media.
5. Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.

Claimen dat dit geen GRUB probleem is, maar een Windows probleem op z'n zachtst gezegd misleidend.
30-07-2020, 12:47 door [Account Verwijderd] - Bijgewerkt: 30-07-2020, 12:51
Door Anoniem: Het probleem is dat iedere aanvaller nu een Grub2 programma in de bootsector van elke harddisk kan plaatsen. En daarmee Secure Boot volledig kan omzeilen. De aanvaller krijgt dan dezelfde rechten als Grub2. Root dus.

Omdat Grub2 digitaal ondertekend is, moeten alle UEFI biossen geupdated worden zodat ze deze sleutel niet meer gebruiken. Deze sleutel moet in alle UEFI biossen worden ingetrokken.

Of Secure Boot een goed idee van Microsoft was is iets anders. Maar Microsoft heeft wel meer stomme ideeën (zoals autorun.inf, het standaard verbergen van bestandstypes en Macro's in tekst documenten).

Het grootste probleem is dat MS deze fouten niet heeft onderkend en daarom nog altijd geen bugfix heeft weten te ontwikkelen hiervoor. Dit terwijl het om Windows XP bugs ging.
30-07-2020, 13:12 door souplost
Door Anoniem: Het probleem is dat iedere aanvaller nu een Grub2 programma in de bootsector van elke harddisk kan plaatsen. En daarmee Secure Boot volledig kan omzeilen. De aanvaller krijgt dan dezelfde rechten als Grub2. Root dus.

Omdat Grub2 digitaal ondertekend is, moeten alle UEFI biossen geupdated worden zodat ze deze sleutel niet meer gebruiken. Deze sleutel moet in alle UEFI biossen worden ingetrokken.

Of Secure Boot een goed idee van Microsoft was is iets anders. Maar Microsoft heeft wel meer stomme ideeën (zoals autorun.inf, het standaard verbergen van bestandstypes en Macro's in tekst documenten).
Officieel is het dat Secure Boot b.v. bedoeld is om computers in publieke ruimtes te beschermen. Er zijn mensen die zeker weten dat het een poging was om het gebruik van de Linux desktop in te dammen.
30-07-2020, 13:23 door Anoniem
voor de welles-niettes posts hierboven:

Het beveiligingslek, dat de naam BootHole heeft gekregen, raakt dan ook bijna alle Linuxcomputers, alsmede Windowscomputers die van Secure Boot gebruikmaken en de standaard Microsoft Third Party UEFI Certificate Authority vertrouwen.
30-07-2020, 13:25 door souplost - Bijgewerkt: 30-07-2020, 13:29
Door Anoniem:
Door Anoniem: Geen boothole lek in GRUB aangezien het ook in Windows een probleem is. Vreemde misleidende titel. Het enige dat het noemen van Linux en/of GRUB rechtvaardigt is het feit dat deze kwestbaarheid als eerste gevonden is in Linux.
Het is wel degelijk een GRUB lek, dat staat zelfs letterlijk in de tweede zin in het bronartikel:

All operating systems using GRUB2 with Secure Boot must release new installers and bootloaders.

Met vervolgens de lijst met mitigerende maatregelen:

1. Updates to GRUB2 to address the vulnerability.
2. Linux distributions and other vendors using GRUB2 will need to update their installers, bootloaders, and shims.
3. New shims will need to be signed by the Microsoft 3rd Party UEFI CA.
4. Administrators of affected devices will need to update installed versions of operating systems in the field as well as installer images, including disaster recovery media.
5. Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.

Claimen dat dit geen GRUB probleem is, maar een Windows probleem op z'n zachtst gezegd misleidend.
Beter lezen graag. Hij zegt niet dat het een windowsprobleem is maar "ook" . Er hoeft zelfs geen grub2 op te staan.
Volgens Redhat is er geen mitigerende maatregel https://access.redhat.com/security/cve/cve-2020-10713
30-07-2020, 14:33 door Open source gebruiker
Door Anoniem: voor de welles-niettes posts hierboven:

Het beveiligingslek, dat de naam BootHole heeft gekregen, raakt dan ook bijna alle Linuxcomputers, alsmede Windowscomputers die van Secure Boot gebruikmaken en de standaard Microsoft Third Party UEFI Certificate Authority vertrouwen.

Wat het ook mag zijn,
zojuist de GRUB2 update in Linux Mint uitgevoerd.
30-07-2020, 14:47 door Anoniem
Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
30-07-2020, 16:06 door [Account Verwijderd] - Bijgewerkt: 30-07-2020, 16:08
Booten van removable media uit en alleen booten van specifieke drive. En een wachtwoord op de BIOS zodat het niet meer kan worden aangezet. Dan moeten ze in ieder geval je computer openschroeven en drives gaan verwisselen, zodat hun drive in plaats van de bootable drive kan worden gezet. En dan moet de echte bootable drive nog worden beschreven met de veranderde bootsector. Wacht! Is het dan niet gemakkelijker om de drive eruit te schroeven en die even aan een laptop te hangen? Jazeker. Als de bootsector op de bootable niet is versleuteld dan kan je er zo op schrijven.

Je kan er ook gewoon een sticker op plakken met bericht "Nu 100 bitcoins betalen anders dan kom ik terug en sla er een spijker door!". https://xkcd.com/538/
31-07-2020, 21:30 door Anoniem
Door Anoniem: Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
Ik rhel8. Boot niet meer onder HyperV 2016 . Ik accepteer geen hyperv meer. Het werkt onder rhev en xen, behalve hyperv. Altijd hetzelfde gedonder.
01-08-2020, 07:58 door Anoniem
Door Anoniem:
Door Anoniem: Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
Ik rhel8. Boot niet meer onder HyperV 2016 . Ik accepteer geen hyperv meer. Het werkt onder rhev en xen, behalve hyperv. Altijd hetzelfde gedonder.
https://bugzilla.redhat.com/show_bug.cgi?id=1861977
Dat komt knullig over, helemaal in een distro van een bedrijf dat zich uitdrukkelijk op professionele gebruikers richt.
01-08-2020, 10:51 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
Ik rhel8. Boot niet meer onder HyperV 2016 . Ik accepteer geen hyperv meer. Het werkt onder rhev en xen, behalve hyperv. Altijd hetzelfde gedonder.
https://bugzilla.redhat.com/show_bug.cgi?id=1861977
Dat komt knullig over, helemaal in een distro van een bedrijf dat zich uitdrukkelijk op professionele gebruikers richt.

als ik eerlijk ben is dit de 2e update in 20j die zo een issue heeft bij RHEL die ik tegen ben gekomen. dat is best een goede track record. laten we maar niet vergelijken met anderen, want dan wordt het genant :).
01-08-2020, 13:20 door souplost - Bijgewerkt: 01-08-2020, 13:25
Door Anoniem:
Door Anoniem:
Door Anoniem: Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
Ik rhel8. Boot niet meer onder HyperV 2016 . Ik accepteer geen hyperv meer. Het werkt onder rhev en xen, behalve hyperv. Altijd hetzelfde gedonder.
https://bugzilla.redhat.com/show_bug.cgi?id=1861977
Dat komt knullig over, helemaal in een distro van een bedrijf dat zich uitdrukkelijk op professionele gebruikers richt.
Inderdaad een onvergeeflijke fout. Er is duidelijk te weinig getest terwijl deze fix helemaal niet urgent was volgens RedHat zelf (Moderate). Volgens mijn test zit het reboot probleem in shim pakketje (the version signed by the UEFI signing service).
Eigenlijk ben je al gewaarschuwd tijdens de update zie je dat er selinux attributen geschreven worden naar vfat systeem (/boot/efi/EFI) dat helemaal geen permissie systeem heeft! Deze boothole fix even maar niet installeren op een secureboot systeem.
01-08-2020, 13:40 door souplost
Door Anoniem:
Door Anoniem: Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
Ik rhel8. Boot niet meer onder HyperV 2016 . Ik accepteer geen hyperv meer. Het werkt onder rhev en xen, behalve hyperv. Altijd hetzelfde gedonder.
https://access.redhat.com/solutions/5272311
02-08-2020, 09:20 door Anoniem
Door souplost:
Door Anoniem:
Door Anoniem: Vandaag op Ubuntu LTS 20.4 de update uitgevoerd.
Ik rhel8. Boot niet meer onder HyperV 2016 . Ik accepteer geen hyperv meer. Het werkt onder rhev en xen, behalve hyperv. Altijd hetzelfde gedonder.
https://access.redhat.com/solutions/5272311

en de fixes zijn er ook al:

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.