image

Microsoft komt halverwege 2022 met update voor lek in Grub2-bootloader

zondag 17 april 2022, 09:07 door Redactie, 21 reacties

Microsoft komt halverwege dit jaar met een beveiligingsupdate voor een meerdere kwetsbaarheden in de Grub2-bootloader die een aanvaller code laten uitvoeren tijdens het bootproces. De Grub2-bootloader wordt gebruikt voor het laden van het besturingssysteem. Eind juli 2020 presenteerden onderzoekers van securitybedrijf Eclypsium een kwetsbaarheid genaamd "Boothole" (CVE-2020-10713) waarmee een aanvaller met fysieke toegang of beheerdersrechten willekeurige code kan uitvoeren voordat het besturingssysteem wordt geladen, zelfs wanneer Secure Boot is ingeschakeld.

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 waarschuwde Eclypsium. Naast bijna alle Linuxcomputers raakt het lek ook 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. Na de presentatie van het Boothole-lek werden zowel in 2020 als vorig jaar maar meerdere soortgelijke kwetsbaarheden gevonden. Microsoft kwam met een ongeteste update voor zowel de problemen van 29 juli 2020 als die van 2 maart 2021.

In een update van Microsofts advisory is een vraag over de ongeteste update verschenen en wanneer die verplicht wordt. Daarop laat Microsoft nu weten dat het halverwege 2022 met een beveiligingsupdate komt om de problemen te verhelpen. Verdere details zijn niet gegeven, behalve dat systeembeheerders zich kunnen aanmelden om te worden gewaarschuwd wanneer de patch beschikbaar is.

Reacties (21)
17-04-2022, 09:28 door Anoniem
In Grub2 zelf is het lek in 2020 al gepatcht, zie het eerdere security.nl-bericht waar het artikel naar linkt, en de gerelateerde kwetsbaarheden zijn zo te zien ook verholpen. In de gelinkte advisory van Microsoft wordt geschreven dat er een Windows Update aankomt. Mij is volstrekt onduidelijk welke Windows-component hierdoor geraakt wordt. En waarom wordt die nu pas gepatcht?
17-04-2022, 10:49 door Anoniem
De update moet eerst nog getest worden door de nsa...
Of zij er nog steeds gebruik van kunnen maken, niet of 'het gefixed' is natuurlijk...
17-04-2022, 10:57 door Anoniem
GRUB2 wordt zo te zien nu onderhouden door 3 mensen, waarvan er 2 bij Oracle werken en 2 zo te zien Russen zijn.

Gaat dat dan nu over naar Microsoft? Wordt dit een fork of kun je nog met een optie kiezen om zelf je grub.cfg te kunnen maken?
17-04-2022, 12:04 door Anoniem
Lekker zo.dit geld natuurlijk ook voor win 11...?en het zou alle maal veiliger worden tpm 2.1.....enz enz
nou niet dus....
17-04-2022, 12:26 door Anoniem
Door Anoniem: In Grub2 zelf is het lek in 2020 al gepatcht, zie het eerdere security.nl-bericht waar het artikel naar linkt, en de gerelateerde kwetsbaarheden zijn zo te zien ook verholpen. In de gelinkte advisory van Microsoft wordt geschreven dat er een Windows Update aankomt. Mij is volstrekt onduidelijk welke Windows-component hierdoor geraakt wordt. En waarom wordt die nu pas gepatcht?

Ik denk dat het probleem is dat Grub2 moet worden ondertekend door Microsoft, zodat het op alle Windows PC's werkt.
En dat de ondertekening van de oude Grub2 moet worden ingetrokken zodat je niet de oude Grub2 kan installeren om een computer fysiek over te nemen.

Wie heeft Secure Boot bedacht? Microsoft natuurlijk. Of anders Intel. Tegen boot malware. Heeft het gewerkt? Natuurlijk niet. Het veroorzaakt nieuwe problemen en vergroot de code base.
17-04-2022, 13:56 door waterlelie - Bijgewerkt: 17-04-2022, 14:08
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.

Laat ik duidelijk maken, dat ik een volslagen leek ben op de dit gebied, maar als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is, en wordt zodoende niet door Secure Boot gecontroleerd, en daarmee is dus de zwakste schakel geworden.

Onvoorstelbaar dus, dat al die slimme en ervaren programmeurs deze voorspelbare achilleshiel niet al tijdens het programmeren gealarmeerd heeft. 10 jaar geleden zou ik dit hebben kunnen begrijpen, maar wie nu nog dit soort fouten maakt, is gewoon bewust bezig met saboteren of is totaal incompetent.
En waarom geen eigen security afdeling die al deze aanpassingen intensief test op haar zwaktes, dat zou toch standaard moeten zijn.
17-04-2022, 14:28 door Anoniem
"Laat ik duidelijk maken, dat ik een volslagen leek ben op de dit gebied..."

en dan

"Onvoorstelbaar dus, dat al die slimme en ervaren programmeurs deze voorspelbare achilleshiel niet al tijdens het programmeren gealarmeerd heeft. 10 jaar geleden zou ik dit hebben kunnen begrijpen, maar wie nu nog dit soort fouten maakt, is gewoon bewust bezig met saboteren of is totaal incompetent. "


lekker bezig joh... k heb er geen verstand van maar wel een mening over?

de bug in grub2 is een flinke tijd geleden al gepatched. wat MS hier mee van doen heeft is onduidelijk.
17-04-2022, 16:10 door Anoniem
"Ik denk dat het probleem is dat Grub2 moet worden ondertekend door Microsoft, zodat het op alle Windows PC's werkt."

nee een 'shim' wordt gesigneerd voor UEFI [en die shim checked grub zelf weer]:

https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html
17-04-2022, 16:35 door Ron625
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........
17-04-2022, 18:15 door Anoniem
Door Anoniem: Ik denk dat het probleem is dat Grub2 moet worden ondertekend door Microsoft, zodat het op alle Windows PC's werkt.
En dat de ondertekening van de oude Grub2 moet worden ingetrokken zodat je niet de oude Grub2 kan installeren om een computer fysiek over te nemen.
Grub2 is allang gepatcht en allang weer ondertekend. Die ondertekening loopt niet via Windows Update. Als dat zo was zou je Windows Update nodig hebben om Linux te kunnen installeren op een machine waar helemaal geen Windows op draait met een UEFI die je Secure Boot niet uit laat zetten. Zo werkt het niet. Mijn vriend heeft trouwens een dual-boot-systeem met Linux en Windows en Grub2 als bootloader. Dat werkt — nu, op dit moment.

De advisory van Microsoft waar het artikel naar linkt noemt een revocation list die "limited testing" heeft ondergaan. De pagina erover op uefi.org (waar de advisory naar verwijst) verwijst weer naar een pagina van HP die waarschuwt dat sommige HP-pc's een BIOS-upgrade nodig is voor je de revocation list kan installeren. Anders hangt de pc na installeren of upgraden van Windows, waarna een faciliteit in de HP-BIOS weigert het OS te starten omdat er een ongeautoriseerde wijziging van de Secure Boot Keys zou hebben plaatsgevonden.

Misschien gaat Microsoft deze revocation list via Windows Update verspreiden maar wil men daarbij voorkomen dat systemen in de problemen komen hierdoor. Als ze niet alleen naar HP hebben gekeken maar naar aanleiding van de problemen daar hebben onderzocht of dit ook buiten HP mis kan gaan dan kan ik me voorstellen dat dat een behoorlijke kluif is geweest om uit te zoeken.
17-04-2022, 18:29 door Anoniem
Door Ron625:
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........
Bovendien MOET het wel op de computer zelf worden aangemaakt, want het bevat de opsomming van wat er allemaal
in het bootmenu moet worden opgenomen, en dat is afhankelijk van de diskindeling, wat er allemaal voor OS'en op staan,
enz. Het is dus niet een bestand wat door een distributeur eenmalig aangemaakt en gesigned kan worden.
Het "even signen met een tooltje op de computer" heeft geen zin natuurlijk, want dan moet de secret key ook op de
computer staan en heeft het hele signen geen zin meer.

De fix in grub is dan ook niet om dat bestand te signen, maar om grub beter bestand te maken tegen fouten in het bestand.
17-04-2022, 19:23 door waterlelie
Door Ron625:
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........

En ..

Hoe is het mogelijk, dat top programmeurs van dit soort bedrijven dit gewoon niet hebben voorzien, zo te lezen is dit toch geen hogeschool programmeren.
17-04-2022, 20:19 door Anoniem
Door waterlelie: En ..

Hoe is het mogelijk, dat top programmeurs van dit soort bedrijven dit gewoon niet hebben voorzien, zo te lezen is dit toch geen hogeschool programmeren.
Nee, daar ligt het niet aan. Dit gaat over een configuratiebestand. Dat is niet op elke computer hetzelfde, dat bevat juist de instellingen die per computer kunnen verschillen, en ook nog eens op elk moment gewijzigd kunnen worden. Secure Boot controleert uitvoerbare code, geen configuratiebestanden.

Die uitvoerbare code wordt door een centrale instantie (bestierd door Microsoft) digitaal ondertekend. Daarvoor moeten de makers (Microsoft zelf voor Windows, Linux-distributies en anderen), voor elke release opnieuw de programma's waar het om gaat opnieuw laten ondertekenen.

Als configuratiebestanden ook ondertekend zouden moeten worden dan zouden alle computerbezitters ter wereld hun configuratiebestandjes voor Grub2 en andere bootloaders ook door die centrale instantie moeten laten ondertekenen, niet alleen op het moment dat ze iets installeren, maar elke keer dat er iets in die configuratie wijzigt.

Dat is ondoenlijk, en het zou ook niets oplossen, omdat ook dan een aanvaller een kwaadaardig configuratiebestand op een systeem kan plaatsen, een die als een van de vele, vele configuratiebestandjes gewoon volautomatisch is ondertekend door de centrale instantie en daardoor niet tegengehouden wordt.

Wat hier misging is niet dat het configuratiebestand niet is ondertekend, maar dat Grub2 bugs bevatte die aangevallen konden worden door gekke dingen in het configuratiebestand te zetten. Grub2 is allang gerepareerd, en daarmee is dat probleem verholpen.

En voor de duidelijkheid: bugvrije software is bijna onmogelijk om te maken, en erg duur. De software van de Space Shuttle was bugvrij, of nagenoeg bugvrij. Dat heeft duizenden dollars per regel sourcecode gekost, en een ontwikkeltraject dat eindeloos lang heeft geduurd. Dat is voor de meeste bedrijven volstrekt onbetaalbaar. Als we alle software zo zouden maken dan zouden we maar een fractie van de software hebben die we nu hebben, en die zou schreeuwend duur zijn.

Als gewone software heel grondig getest en verbeterd is zit er misschien ongeveer één fout in per 2000 regels sourcecode. De software op een alledaagse pc heeft vele tientallen miljoenen regels sourcecode. Zelfs als alles die kwaliteit zou halen zouden er nog tienduizenden onontdekte bugs in het geheel zitten. Als een aanvaller zo'n bug kan misbruiken is het meteen een securitylek. De mensheid is simpelweg nog lang niet zo ver dat we software kunnen maken die betaalbaar én foutloos is.
17-04-2022, 21:43 door Anoniem
Door waterlelie:
Door Ron625:
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........

En ..

Hoe is het mogelijk, dat top programmeurs van dit soort bedrijven dit gewoon niet hebben voorzien, zo te lezen is dit toch geen hogeschool programmeren.
Altijd makkelijk reageren met de kennis van NU!
18-04-2022, 07:13 door Anoniem
Iedereen die denkt dat grub van MS is heeft het mis. Het is een gnu project.
18-04-2022, 09:34 door waterlelie - Bijgewerkt: 18-04-2022, 09:36
Door Anoniem:
Door waterlelie:
Door Ron625:
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........

En ..

Hoe is het mogelijk, dat top programmeurs van dit soort bedrijven dit gewoon niet hebben voorzien, zo te lezen is dit toch geen hogeschool programmeren.
Altijd makkelijk reageren met de kennis van NU!

Dat laatste is gelul, 10 jaar geleden zou ik dat nog een acceptabel excuus hebben gevonden, maar de gebruiker wordt nu al vele jaren geconfronteerd met problemen ten gevolge van slecht en armoedig programmeren. Het is niet voor niks, dat bedrijven premies uitloven aan iedereen die een fout in hun programma ontdekt. Hiermee ontlopen ze in feite gewoon hun eigen verantwoordelijkheid om dit zelf te doen.
18-04-2022, 11:54 door Anoniem
Door Anoniem: De advisory van Microsoft waar het artikel naar linkt noemt een revocation list die "limited testing" heeft ondergaan. De pagina erover op uefi.org (waar de advisory naar verwijst) verwijst weer naar een pagina van HP die waarschuwt dat sommige HP-pc's een BIOS-upgrade nodig is voor je de revocation list kan installeren. Anders hangt de pc na installeren of upgraden van Windows, waarna een faciliteit in de HP-BIOS weigert het OS te starten omdat er een ongeautoriseerde wijziging van de Secure Boot Keys zou hebben plaatsgevonden.

Misschien komt er een halfjaarlijkse update van Windows 10 (en 11) die je verplicht eerst een BIOS/UEFI upgrade te doen. Microsoft kan dan meteen dingen als TPM aanzetten in het BIOS op een manier die niet meer uit te schakelen is.

Ik zie dit niet zo snel gebeuren. Bovendien ben ik al lang weg van Windows voor ik die melding ga krijgen.

Anoniem 12:26

P.S. De laptop van mijn vader kreeg kortgeleden onder Windows 10 een firmware bios update aangeboden als optionele update. Er was toen al weer een nieuwere versie van de fabrikant zelf beschikbaar maar dit kan tegenwoordig kennelijk via Windows zelf. De fabrikant van mijn vader's laptop waarschuwt op de site tegen het downgraden naar een oudere bios versie. Lekker bezig Microsoft.
18-04-2022, 11:59 door Anoniem
Door waterlelie: Dat laatste is gelul, 10 jaar geleden zou ik dat nog een acceptabel excuus hebben gevonden, maar de gebruiker wordt nu al vele jaren geconfronteerd met problemen ten gevolge van slecht en armoedig programmeren. Het is niet voor niks, dat bedrijven premies uitloven aan iedereen die een fout in hun programma ontdekt. Hiermee ontlopen ze in feite gewoon hun eigen verantwoordelijkheid om dit zelf te doen.

Je begon gisteren met duidelijk te maken dat je een volslagen leek ben op dit gebied en te zeggen dat je gevoelsmatig redeneert, en vervolgens blijf je maar doorgaan alsof je het allemaal veel beter weet dan mensen die geen volslagen leek zijn.

Stop daar eens mee. Je komt niet sterk over zo, je zet jezelf te kijk. Het is heel wat sterker om als je ergens geen verstand van hebt dat gewoon toe te geven en er niet moeilijk over te doen dan wat jij nu doet.
18-04-2022, 12:52 door Anoniem
Door waterlelie:
Door Anoniem:
Door waterlelie:
Door Ron625:
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........

En ..

Hoe is het mogelijk, dat top programmeurs van dit soort bedrijven dit gewoon niet hebben voorzien, zo te lezen is dit toch geen hogeschool programmeren.
Altijd makkelijk reageren met de kennis van NU!

Dat laatste is gelul, 10 jaar geleden zou ik dat nog een acceptabel excuus hebben gevonden, maar de gebruiker wordt nu al vele jaren geconfronteerd met problemen ten gevolge van slecht en armoedig programmeren. Het is niet voor niks, dat bedrijven premies uitloven aan iedereen die een fout in hun programma ontdekt. Hiermee ontlopen ze in feite gewoon hun eigen verantwoordelijkheid om dit zelf te doen.
Nee dat is het niet. De factor tijd die is toegekend is bepalend. Waarom zou je je als programmeur uit de naad werken voor een groot gesloten commercieel bedrijf zoals microsoft tegen een middelmaat salaris? en dat weten ze vandaar die programma's.
Dat de "project" features precies op tijd af zijn is veel belangrijker dan security anders haal je je target niet.
18-04-2022, 16:00 door waterlelie
Door Anoniem:
Door waterlelie:
Door Anoniem:
Door waterlelie:
Door Ron625:
Door waterlelie:als ik gevoelsmatig redeneer, dan lees ik dus dat een eenvoudig bestandje grub.cfg niet digitaal gesigneerd is
Dat eenvoudige bestandje is bij mij bijna 60k groot..........

En ..

Hoe is het mogelijk, dat top programmeurs van dit soort bedrijven dit gewoon niet hebben voorzien, zo te lezen is dit toch geen hogeschool programmeren.
Altijd makkelijk reageren met de kennis van NU!

Dat laatste is gelul, 10 jaar geleden zou ik dat nog een acceptabel excuus hebben gevonden, maar de gebruiker wordt nu al vele jaren geconfronteerd met problemen ten gevolge van slecht en armoedig programmeren. Het is niet voor niks, dat bedrijven premies uitloven aan iedereen die een fout in hun programma ontdekt. Hiermee ontlopen ze in feite gewoon hun eigen verantwoordelijkheid om dit zelf te doen.
Nee dat is het niet. De factor tijd die is toegekend is bepalend. Waarom zou je je als programmeur uit de naad werken voor een groot gesloten commercieel bedrijf zoals microsoft tegen een middelmaat salaris? en dat weten ze vandaar die programma's.
Dat de "project" features precies op tijd af zijn is veel belangrijker dan security anders haal je je target niet.

Nu begint helaas de discussie op trollen gedrag te lijken, een goed moment om af te sluiten..
19-04-2022, 15:04 door Anoniem
Door Anoniem:

Wie heeft Secure Boot bedacht? Microsoft natuurlijk. Of anders Intel. Tegen boot malware. Heeft het gewerkt? Natuurlijk niet. Het veroorzaakt nieuwe problemen en vergroot de code base.
SecureBoot is niet door Microsoft bedacht. Secure Boot is een idee van Intel.
Microsoft's ontwikkeling voor Secure boot bestaat voornamelijk uit het standaardiseren ervan zodat het goed in een OS opgenomen kan worden.

Het maakt het overigens wel degelijk een stuk lastiger (niet onmogelijk) om een systeem te exploiten. Het is niet zaligmakend, anders waren Secure Enclaves of TPM niet nodig geweest.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.