Patch voor BootHole-bug in Grub2 zorgt voor opstartproblemen in Linux-distro's

De patches die deze week zijn uitgebracht voor een bug in de Grub2-bootloader veroorzaken problemen bij verschillende Linux-distributies. Sommige gebruikers van Red Hat, Ubuntu, CentOS, en Debian melden dat ze hun systemen niet meer kunnen opstarten.

De problemen zijn ontstaan nadat ontwikkelaars patches uitbrachten om de BootHole-kwetsbaarheid te verhelpen. Die bug in Grub2 maakt apparaten met Secure Boot kwetsbaar, al is het in de praktijk moeilijk dat lek uit te buiten. Omdat het lek in Grub2 zit zijn vrijwel alle Linux-systemen kwetsbaar. Ontwikkelaars zoals Red Hat en Canonical hebben daarin na melding van de onderzoekers patches uitgebracht.

Inmiddels lijkt het erop dat die patches niet overal even goed werken. Onder andere in de bugtracker van Red Hat, Ubuntu, CentOS, en Debian klagen gebruikers dat hun systemen niet meer opstarten. Grub2 is een bootloader die gebruik maakt van Microsoft als certificaatautoriteit. Een bug in die bootloader of verkeerd geconfigureerde cryptografische ondertekeningen kunnen er dus voor zorgen dat een systeem helemaal niet meer werkt. Dat kan verschillen per systeem en distributie. Hoe groot het probleem precies is, is dan ook moeilijk te zeggen.

In de bugreports schrijven gebruikers dat terugdraaien naar een vorige versie van Grub2 via een bootable iso genoeg lijkt om het probleem op te lossen. Ze blijven dan wel kwetsbaar voor de BootHole-kwetsbaarheid. Ook het uitschakelen van Secure Boot zou een oplossing kunnen zijn.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (42)

Heb dit bij mijn laptop gefixed met https://help.ubuntu.com/community/Boot-Repair via usb.

Het uitschakelen van Secure Boot is natuurlijk geen oplossing. De bug bestond er net in dat kwaadwillenden eventueel code konden injecteren ondanks dat Secure Boot aan stond. Dan lijkt het mij dat je deze niet zomaar wenst uit te schakelen. Dan kan je beter zonder de gepatchte versie werken.

Het uitschakelen van Secure Boot is natuurlijk geen oplossing. De bug bestond er net in dat kwaadwillenden eventueel code konden injecteren ondanks dat Secure Boot aan stond. Dan lijkt het mij dat je deze niet zomaar wenst uit te schakelen. Dan kan je beter zonder de gepatchte versie werken.

Zoals ik al schetste is de beveiliging van Secure Boot beperkt ten opzichte van de prijs. Door het bestaan van binaries ondertekend door Microsoft die doorstarten met onveilige code mogelijk maken is Secure Boot een wassen neus.

Zoals wel vaker vergeet men dat beschikbaarheid ook een pilaar is van informatiebeveiliging. Die wordt door Secure Boot en de daarbij behorende problemen zoals genoemd in het artikel zwaar onder druk gezet.

Als 'fire and forget' beveiliging heeft Secure Boot gefaald. Met het nodige maatwerk door de gebruiker zou het beveiliging kunnen toevoegen, maar dat is onrealistisch voor de massa.

[Reactie gewijzigd door The Zep Man op 31 juli 2020 18:03]

Op ieder persoonlijk x86 systeem met UEFI schakel ik als eerste Secure Boot uit, omdat ik niet afhankelijk wil zijn van een door Microsoft ondertekende sleutel. Dat de beveiliging dan niet beter is dan op een x86 systeem met een BIOS neem ik dan maar voor lief.

Als er dan toch zulke functionaliteit nodig is, maak ik liever gebruik van iets als FlexVer (voor Talos II workstations), waarbij je zelf de hele stack kunt auditen en sleutels kunt genereren en intrekken. In een black box zoals bij UEFI met Secure Boot heb ik totaal geen vertrouwen.

Je kan vaak ook je eigen sleutels toevoegen, soms ook de Microsoft sleutel weghalen. Hiermee zorg je voor een behoorlijk veilig systeem. Het is wel een behoorlijk gedoe, zie bijvoorbeeld: https://www.linuxjournal....-your-pc-uefi-secure-boot

Ik zal er eens naar kijken op een ouder systeem. Jammer genoeg is Linux Journal er inmiddels ook mee opgehouden, maar hopelijk blijven oude artikelen zoals dit gewoon beschikbaar.

Same here. Als iemand remote genoeg access heeft om een ander kernel image te installeren, dan kan ie genoeg rottigheid uithalen in het stadium na de secure-boot fase. Dat hele secure boot voegt voor een huis-tuin-en-keuken gebruiker m.i. alleen schijnveiligheid toe.

Als iemand inbreekt in mijn huis heb ik wel andere kopzorgen dan dat ie wellicht een gehackte kernel zou installeren :-)

Dit is echter wel forumreactie nummer 1 bij topics over SecureBoot (of SELinux of AppArmor wat dat betreft): Je kan het maar beter uitzetten. Het is een afweging die voor veel gebruikers het verschil is tussen een quick fix of daadwerkelijk inzicht krijgen in hoe de beveiliging is ontworpen (en ze afwegen om beveiliging dan maar te laten)

Waar schrijf ik dat je het moet uitzetten? Ik schrijf net dat uitzetten geen oplossing is omdat je het aan hebt staan met een reden en je na een rollback naar de vorige versie beter af bent omdat dat nog altijd andere toegang vereist om root rechten te krijgen voor je de bug kunt misbruiken. Door SB uit te zetten stel je je net kwetsbaarder op.

Ik reageerde op de stelling dat je beveiliging niet zomaar moet uitzetten.

Ik ben het er mee eens dat beveiliging zoals Secure Boot niet als quick fix uitgeschakeld moet worden.
Ik kan me verenigen in standpunten voor of tegen het afzwakken van beveiliging, maar de vrijheid krijgen het in te stellen zoals je dat zelf wil vind ik belangrijker. Je bent daar uiteindelijk zelf verantwoordelijk voor.

Secure Boot is gebaseerd op certificaten van Microsoft. Persoonlijk ben ik enthousiaster over Coreboot van System 76

Lol. In de Debian log kun je zien dat de tijd tussen de melding en een fix die gepushed is naar de repo ongeveer 8 uur is.

Ik vind het goede aan dit model dat de beheerders opties hebben.
Bij een commerciele closed-source leverancier worden patches meestal eerst uitgebreid getest en dan pas vrijgegeven. Dat zorgt voor hoge kwaliteit, maar het kan wel een tijd duren.

Bij Debian gebeurt veel (doch niet alles) in het openbaar en kun je zelf meekijken, meedenken, en je eigen keuzes maken. Misschien accepteer je de risico's van een slecht getest patch, misschien wacht je liever tot je zekerheid hebt dat het foutloos werkt. Omdat de hele discussie ook in het openbaar plaats vindt heb je alle informatie om zelf een weloverwogen keuze te maken. Je moet natuurlijk wel de kennis hebben om zelf een inschatting te kunnen maken, maar als je die kennis hebt dan kun je er gebruik van maken.

update: s/commerciele/closed-source/

[Reactie gewijzigd door CAPSLOCK2000 op 31 juli 2020 20:04]

Bij een commerciele leverancier worden patches meestal eerst uitgebreid getest en dan pas vrijgegeven. Dat zorgt voor hoge kwaliteit, maar het kan wel een tijd duren.

Red Hat had anders zeer snel een update voor GRUB2 beschikbaar, snel genoeg dat die bij de maandelijkse patchronde van deze week mee kwam. En inmiddels zitten we met een aantal RHEL werkstations die niet meer willen booten en heb ik vandaag met klem benadrukt dat men het werkstation vandaag aan het eind van de dag niet moet uitschakelen, omdat ze dan zeer waarschijnlijk maandag niet meer willen starten. Dus ja, ik heb nog wel een appeltje te schillen met Red Hat wat betreft hun tests...

Bij mij werkte de oplossing zoals hier gemeld bij comment 32, scheelt best wel wat werk.

https://bugzilla.redhat.com/show_bug.cgi?id=1861977

Ik zie eigenlijk alleen mensen die rapporteren dat het werkt op RHEL 8, werkt deze oplossing ook voor RHEL 7? Met andere woorden, is de shim hetzelfde voor beide versies van RHEL?

Ik heb helaas geen centos7 draaien, veel moeite kost het niet om het te proberen, Ik ben geen Linux expert maar volgens mij zou het moeten werken.

Complicerende factor is wel dat de mate van testen niet eenvoudig beschikbaar is.

Ik was een van de ongelukkigen die gisteravond voor het eerst na de vakantie een apt update uitvoerde en getrakteerd werd met een Debian systeem dat niet meer bootte. Grub was slechts een van de packages die geupdate werd.

Voor een stable release was deze patch, zelfs voor security, veel te gehaast.

Overigens hoeft men niet terug naar de oude versie zoals gesteld in het artikel. Grub even (geforceerd) installeren/updaten op de juiste (boot)disk fixt het.

Ik lipe er op m'm Ubuntu LTS ook tegenaan, en heb het als relatieve *nix n00blet ook gefixed (door precies jouw methode, handmatig de juiste 'installatiepartitie'/disk kiezen).

Die hoge kwaliteit durf ik te betwijfelen.

Ik wist dat ik commentaar ging krijgen...

Vooruit, "van hogere kwaliteit dan helemaal zonder testen".

Happy to oblige

Software is moeilijk en bedrijven bekijken alles vanuit de bottomline, dus ja ik vond het iets te kort door de bocht.

Misschien een beetje kort door de bocht. Ondanks dat Microsoft ook genoeg bugs en problemen veroorzaakt, staan ze wel vrij eenzaam bovenaan met het aantal fouten per duizend regels code.

Alleen ruimtevaart organisaties doen dit beter.

Het is ergens wel een voorbeeld dat closed source beter _kan_ zijn op gebied van kwailteit.

Tja, alles _kan_.

Vrijwel alles wat je zegt geldt ook voor commerciële leveranciers. Treedt daar een bug op gaan er genoeg mensen zeuren. Ook daar kun je, mits je de kennis hebt, zelf een goede overweging maken. Ook daar kies je om direct te installeren en het risico te lopen op slechte geteste patches of om ff een weekje te wachten. Ook daar is de discussie openbaar op het moment dat het een grote bug is en op alle fora mensen gaan klagen.

Wat ik mis in je verhaal (staat er wel, maar slecht), als je zelf kennis hebt van programmeren (wat zeker niet elke Linux beheerder heeft) en van het onderwerp, kun je de patch zelf uitpluizen om te bepalen of de patch een hoog of laag risico vormt.

Patches die te maken hebben met het bootproces zou ik ook op Windows direct als groot risico vlaggen in implementatie en eerst op testservers uitproberen.

[Reactie gewijzigd door SunnieNL op 31 juli 2020 18:06]

Denk dat je over zijn 2e zin hebt heen gelezen of niet helemaal snapt wat hij bedoelt.

6 uur, verschillende berichten hebben een andere tijdzone

Schijnbaar is het “probleem” dat Windows niet meer gestart kan worden, de Linux installie kan wel geboot worden.

Sounds like a new feature to me

Haha, ik was al benieuwd hoe je die fix terug moest draaien als je systeem niet meer boot.

Maar je geeft indirect antwoord op mijn vraag

Als je bootloader niet meer werkt onder Linux dan kan je opstarten met een CD/DVD/USB, in een rescue mode gaan, je harde schijf opzetten zodat het systeem denkt dat je op de schijf bezig bent en dan gewoon je bootloader herstellen.

Of, via live versie linux (USB) boot-repair installen en runnen. Daarna update-grub en je hebt je bootmenu ook weer terug. Tis wel een luie huiswijven methode, die zeker niet altijd bij iedereen werkt, maar voor mij werkte deze razendsnel en zat weer in no time online te werken.

Ik had het tot nu toe gedaan met de Live USB-Stick draaien en dan versie terug gaan met TimeShift.
Updates draaien en klaar.
Maar dat commando ga ik ook nog ff proberen. We hebben binnen het bedrijf nog wel een paar laptops die niet meer werken.

Waar zie je dat? Ik lees overal toch echt dat Linux-systemen zelf niet meer bootable zijn.

Jammer dat ik dit nu pas lees. Bij het installeren van MX linux kwam er een melding over bad sector op de ssd. Na een reboot startte het systeem niet meer door.

Clean install van Ubuntu gedaan en na reboot hetzelfde probleem. Ik dacht eigenlijk gelijk aan een hardware probleem aangezien deze machine al 3 moederbordswaps heeft gehad ivm eerdere defecten. Vandaag is de laptop opgehaald door ups...

Alsof er intentioneel de patches door de CI/CD heen zijn getrapt om ze maar zo snel mogelijk de deur uit te doen

Dat software niet goed getest word weet iedereen, maar BOOT SOFTWARE die niet goed getest word is toch wel echt onacceptabel?
De volgende stap is BIOS Firmware die niet goed getest word...
En wat komt daarna, CPU Firmware die niet goed getest word?
Wat is nou de echte oorzaak hiervan?
Bezuiningingen? Vakantieperiode? Stagaire die de code commit heeft gedaan?
Waarom stelt niemand die vraag?

Fijn.....

Had dit nog niet gelezen dus zojuist even mijn 2 Debian servertjes een upgrade gegeven van Buster 5.4 naar Buster 5.5.
Beiden reboot en ja hoor, Grub in rescue mode......

Uur bezig geweest met servers loshalen (headless), toetsenbord en muis aanknopen en via usb stick backup van tijdje terug recoveren.
Dit soort gekloot kan toch niet als je Debian stable draait...

edit: is trouwens geen dual boot systeem en ook geen secure boot enabled. Stond toch tegen een "grub rescue" aan te staren

[Reactie gewijzigd door GG85 op 1 augustus 2020 16:35]

Ik gebruik ook Ubuntu (mate) tweemaal maar ik weet niet of daar grub2 bij zit. Gok van wel. Ik ben dus wel kwetsbaar en kan beter even wachten met updaten?

Overigens, hoe ernstig is dit lek voor mij als je er root rechten voor nodig hebt?

Je kunt wel upgraden, maar hij zal waarschijnlijk beginnen te bokken dat hij niet automatisch kan installeren. Als je vervolgens de automatische installatie (die immers toch niet werkt) afbreekt en in het volgende scherm alsnog handmatig de juiste partitie/disk kiest komt het goed. In geval van twijfel kun je zelfs al je disks selecteren en RGUb2 overal installeren (ook al weet ik eerlijk gezegd niet of je daar in tweede instantie mee in de problemen komt -- duidelijker zal het er niet op worden ).

En als je het je kunt veroorloven om te wachten totdat de versie in de repo's al geherpatched is is dat natuurlijk ook mooi. Ik wist nog niet van deze bug toen ik hem upgrad...bijwerkte.

Ik weet niet waar je die informatie vandaan haalt, maar het klopt niet. Dankzij de nieuwe versie van GRUB2 heb ik meerdere Red Hat werkstations op mijn werk die na updates niet meer willen starten.

Van die bug heb ik hier totaal geen last

In het bovenstaande bugreport wordt gesproken over 2.04-1ubuntu26.1 terwijl 2.04-1ubuntu26.2 nu te installeren is. Het lijkt er op dat de laatste versie een fix heeft voor de fout:

2020-07-30 - Steve Langasek <[e-mail]>
grub2 (2.04-1ubuntu26.2) focal; urgency=medium
* debian/postinst.in: Avoid calling grub-install on upgrade of the grub-pc
package, since we cannot be certain that it will install to the correct
disk and a grub-install failure will render the system unbootable.
LP: #1889556.

Meer info