Matthew Garrett, een bekende Linux-kernelontwikkelaar die ooit een prijs van de Open Source Foundation ontving voor zijn bijdrage aan de ontwikkeling van open source software, sprak over de essentie van het SBAT (Secure Boot Advanced Targeting) mechanisme, dat is ontworpen om kwetsbaarheden in de bootloader te blokkeren zonder digitale handtekeningen in te trekken. Hij vertelde ook over de rol die het speelde in het recente incident met een update voor Windows, die leidde tot het stoppen van de opstart van enkele Linux-distributies die parallel met Windows waren ge\u00efnstalleerd op systemen met ingeschakelde UEFI Secure Boot. Kort samengevat is de verantwoordelijkheid verdeeld tussen Microsoft, dat de update niet volledig had getest en deze toepaste op systemen waarop deze niet had moeten worden toegepast, en de ontwikkelaars van enkele Linux-distributies, die de GRUB-bootloader en de SBAT-generatienummers niet hadden bijgewerkt toen er kwetsbaarheden in GRUB werden ontdekt. <\/p>\n
Hieronder volgt de vertaling van Garretts notitie: <\/p>\n
\nToen de specificatie voor UEFI Secure Boot werd ontwikkeld, waren alle deelnemers, laten we zeggen, een beetje na\u00efef. Het belangrijkste beveiligingsmodel van Secure Boot is dat alle code die in een geprivilegieerde omgeving op kernel-niveau draait, moet worden gevalideerd voordat deze wordt uitgevoerd \u2014 de firmware controleert de bootloader, de bootloader controleert de kernel, de kernel controleert elke aanvullende code die tijdens de uitvoering wordt geladen, en nu hebben we een vertrouwde omgeving om elk ander beveiligingsbeleid dat we willen op te leggen. Het is duidelijk dat mensen fouten kunnen maken, maar in de specificatie was er een manier voorzien om ondertekende componenten die zich als onbetrouwbaar hebben bewezen, in te trekken: voeg eenvoudig de hash van de onbetrouwbare code toe aan een variabele en weiger vervolgens om iets met die hash te laden, zelfs als het is ondertekend met een vertrouwd sleutel. <\/p>\n
Helaas bleek het probleem de schaal te zijn. Elke Linux-distributie die draait in het Secure Boot-ecosysteem genereert zijn eigen opstartloader-binaire bestanden, en elk daarvan heeft zijn eigen hash. Als er in de broncode van zo'n opstartloader een kwetsbaarheid wordt ontdekt, moeten er veel verschillende binaire bestanden worden ingetrokken. Het geheugen dat beschikbaar is voor het opslaan van de variabele met al deze hashes is beperkt. Er is gewoon niet genoeg ruimte om elke keer dat blijkt dat GRUB (de opstartloader, oorspronkelijk geschreven in een tijd waarin er geen bescherming bij het opstarten werd toegepast en met verschillende afzonderlijke parsers voor img-afbeeldingen, evenals een lettertypeparser) een ander mechanisme heeft voor een aanvaller om het te dwingen willekeurige code uit te voeren, een nieuwe set hashes toe te voegen, daarom was een andere oplossing nodig. <\/p>\n
De oplossing hiervoor is SBAT geworden. Het algemene concept van SBAT is vrij eenvoudig. Elk belangrijk component in de opstartketen verklaart zijn beveiligingsgeneratie, die wordt opgenomen in het ondertekende binaire bestand. Wanneer een kwetsbaarheid wordt ontdekt en verholpen, wordt deze generatie verhoogd. Vervolgens kan er een update worden uitgebracht die de minimale generatie definieert \u2014 opstartcomponenten zullen naar het volgende element in de keten kijken, de naam en generatie vergelijken met die in de firmwarevariabele en beslissen of ze deze al dan niet moeten uitvoeren op basis hiervan. In plaats van een groot aantal afzonderlijke hashes in te trekken, kan er \u00e9\u00e9n update worden uitgebracht die gewoon zegt: \u2018Elke versie van GRUB met een beveiligingsgeneratie lager dan dit nummer wordt als onbetrouwbaar beschouwd.\u2019 <\/p>\n
Waarom is dit opeens zo belangrijk geworden? SBAT is ontwikkeld in samenwerking met de Linux-gemeenschap en Microsoft, en Microsoft heeft besloten een update voor Windows uit te brengen die systemen vertelde niet te vertrouwen op versies van GRUB met een beveiligingsgeneratie onder een bepaald niveau. Dit werd gedaan omdat deze versies van GRUB echte beveiligingskwetsbaarheden hadden die kwaadwillenden in staat stelden de veilige opstartketen van Windows te doorbreken, en we hebben echte voorbeelden gezien van malware die dit wilde doen (Black Lotus gebruikte een kwetsbaarheid in de Windows-opstartloader, maar de kwetsbaarheid in GRUB was even effectief). Als je dit puur vanuit een beveiligingsperspectief bekijkt, is het een volkomen legitieme wens. <\/p>\n
Wat betreft de boodschap \u2018Er is iets heel verkeerd gegaan\u2019 en de onmogelijkheid om op te starten als gevolg van deze update. Dit wordt afgehandeld door shim, en niet door enige code van Microsoft. Shim houdt rekening met de SBAT-updates, en om de beveiligingsprincipes die door andere bootloaders in het systeem zijn aangenomen niet te schenden, en hoewel Microsoft een SBAT-update heeft uitgebracht, weigert de Linux-bootloader alsnog om oude versies van GRUB op te starten. Alles werkt zoals het hoort. <\/p>\n
Het probleem waar mensen tegenaan lopen, is dat verschillende Linux-distributies geen GRUB-versies met een nieuwere beveiligingsgeneratie hebben uitgebracht, waardoor deze GRUB-versies als onveilig worden beschouwd (het is vermeldenswaard dat GRUB door de distributies zelf wordt ondertekend en niet door Microsoft, dus er is hier geen externe achterstand). Het plan van Microsoft was dat de Windows Update de SBAT-update alleen zou toepassen op systemen die alleen met Windows werken, terwijl alle dual-boot-installaties kwetsbaar zouden blijven voor aanvallen totdat de ge\u00efnstalleerde distributie GRUB zou bijwerken en de SBAT-generatie zou vernieuwen. Helaas, zoals nu duidelijk is, werkte dit niet zoals bedoeld en pasten ten minste sommige dual-boot-systemen de update toe, terwijl deze distributie-shim weigerde om GRUB van deze distributie op te starten. <\/p>\n
Wat is de conclusie? Microsoft wilde (om begrijpelijke redenen) niet dat Windows kon worden aangevallen via een kwetsbare versie van GRUB, die op een misleidende manier zou kunnen worden aangestuurd om willekeurige code uit te voeren en vervolgens een bootkit in de kern van Windows tijdens het opstarten te injecteren. Microsoft heeft dit opgelost door een Windows-update uit te brengen die de SBAT-variabele bijwerkte, met de mededeling dat kwetsbare versies van GRUB niet op deze systemen moesten worden geladen. De door de distributie geleverde Shim-opstartlader in de eerste fase las deze variabele, las de SBAT-sectie van de ge\u00efnstalleerde GRUB-versie, begreep dat ze conflicteerden en weigerde GRUB te laden met het bericht 'Er ging echt iets mis'. Deze update was niet bedoeld voor systemen met dual boot, maar werd toch toegepast. <\/p>\n
Samenvattend: <\/p>\n
1) Microsoft paste de update toe op systemen waar deze niet op toegepast had moeten worden. <\/p>\n
2) Sommige Linux-distributies hebben de GRUB-bootloader en de SBAT-beveiligingsgeneratie niet bijgewerkt, toen kwetsbaarheden in GRUB werden ontdekt. <\/p>\n
Als gevolg hiervan kunnen sommige mensen hun systemen niet opstarten. Ik denk dat er hier veel schuldigen zijn. Microsoft zou meer tests moeten uitvoeren om ervoor te zorgen dat dual-boot-installaties nauwkeurig kunnen worden herkend. Maar ook distributies die ondertekende opstartprogramma's aanbieden, moeten ervoor zorgen dat ze deze bijwerken en de beveiligingsgeneratie bijwerken om aan te sluiten, want anders bieden ze een aanvalsvector die kan worden gebruikt om andere besturingssystemen te hacken, en dat is een soort schending van de sociale overeenkomst eromheen. <\/p>\n
Helaas zijn de slachtoffers hier voornamelijk eindgebruikers die geconfronteerd worden met het feit dat hun systeem plotseling weigert op te starten naar het besturingssysteem dat ze willen opstarten. Dit zou nooit moeten gebeuren. Ik denk niet dat het ondervragen van eindgebruikers over hun wens voor updates van veilige opstartmogelijkheden een goed resultaat zal opleveren, en hoewel ik vaag neig naar het idee dat veilige UEFI-opstart niet iets is dat de meeste eindgebruikers ten goede komt, is het ook iets dat je niet wilt ontdekken na dergelijke incidenten. Daarom sympathiseer ik met de keuze om het standaard ingeschakeld te hebben, en ik steun de beslissing van Microsoft, behalve de mislukte poging om upgrades op dual-boot-systemen te vermijden. <\/p>\n
Hoe dan ook, ik was in 2012 sterk betrokken bij de implementatie van deze mechanismen voor Linux en schreef de eerste prototype Shim (die nu een aanzienlijk betere opstarter is, ondersteund door een breder publiek, en aan de welke ik al enkele jaren niet meer heb gewerkt). Dus als je iemand de schuld wilt geven, ben je vrij om mij te beschuldigen. Dit had niet mogen gebeuren, en als je niet Microsoft of een Linux-distributie bent, is het niet jouw schuld. Mijn excuses daarvoor. <\/p><\/blockquote>\n