Microsoft komt halverwege 2022 met update voor lek in Grub2-bootloader
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.
Of zij er nog steeds gebruik van kunnen maken, niet of 'het gefixed' is natuurlijk...
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?
nou niet dus....
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Dat de "project" features precies op tijd af zijn is veel belangrijker dan security anders haal je je target niet.
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.
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.
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..
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.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.