Boothole-lek in Grub2-bootloader laat aanvaller code uitvoeren tijdens bootproces
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.
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.
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.
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).
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/
Met vervolgens de lijst met mitigerende maatregelen:
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.
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.
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).
Met vervolgens de lijst met mitigerende maatregelen:
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.
Volgens Redhat is er geen mitigerende maatregel https://access.redhat.com/security/cve/cve-2020-10713
Wat het ook mag zijn,
zojuist de GRUB2 update in Linux Mint uitgevoerd.
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/
Dat komt knullig over, helemaal in een distro van een bedrijf dat zich uitdrukkelijk op professionele gebruikers richt.
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 :).
Dat komt knullig over, helemaal in een distro van een bedrijf dat zich uitdrukkelijk op professionele gebruikers richt.
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.
en de fixes zijn er ook al:
https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
