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ĆÆnstalleerd 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.
Hieronder volgt de vertaling van Garretts notitie:
Toen de specificatie voor UEFI Secure Boot werd ontwikkeld, waren alle deelnemers, laten we zeggen, een beetje naĆÆef. Het basis beveiligingsmodel van Secure Boot houdt in dat alle code die wordt uitgevoerd in een bevoorrechte omgeving op kernel-niveau, moet worden gecontroleerd voordat deze wordt uitgevoerd ā de firmware controleert de bootloader, de bootloader controleert de kernel, de kernel controleert alle extra tijdens runtime geladen kernelcode, en nu hebben we een vertrouwde omgeving om elk ander beveiligingsbeleid af te dwingen dat we willen. Het is duidelijk dat mensen fouten kunnen maken, maar de specificatie voorzag in een manier om ondertekende componenten die onbetrouwbaar bleken te zijn, in te trekken: voeg gewoon de hash van de onbetrouwbare code toe aan een variabele en weiger vervolgens alles met deze hash op te starten, zelfs als het met een vertrouwd sleutel is ondertekend.
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.
Deze oplossing werd SBAT. Het algemene concept van SBAT is vrij eenvoudig. Elk belangrijk component in de opstartketen verklaart een beveiligingsgeneratie, die in het ondertekende binaire bestand wordt opgenomen. Wanneer een kwetsbaarheid wordt ontdekt en verholpen, wordt deze generatie verhoogd. Vervolgens kan er een update worden uitgebracht die de minimale generatie definieert ā opstartcomponenten kijken naar het volgende element in de keten, vergelijken de naam en het generatie-nummer met die in de firmwarevariabele en beslissen of ze het al dan niet moeten uitvoeren op basis hiervan. In plaats van een groot aantal afzonderlijke hashes in te trekken, kan er Ć©Ć©n update worden uitgebracht die eenvoudig zegt: 'Elke versie van GRUB met een beveiligingsgeneratie lager dan dit nummer wordt als onbetrouwbaar beschouwd.'
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.
Wat betreft de melding "Er is iets helemaal mis gegaan" en de onmogelijkheid om op te starten als gevolg van deze update. Dit wordt veroorzaakt door shim en niet door een code van Microsoft. Shim houdt rekening met SBAT-updates, en om de beveiligingsprincipes die door andere bootloaders in het systeem zijn aangenomen niet te schenden, terwijl Microsoft een SBAT-update heeft uitgegeven, weigert de Linux-bootloader om oude versies van GRUB op te starten. Alles werkt zoals het zou moeten.
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ĆÆnstalleerde 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.
Wat is de conclusie? Microsoft wilde begrijpelijkerwijs niet dat Windows kon worden aangevallen met een kwetsbare versie van GRUB, die op een misleidende manier zou kunnen worden gebruikt om willekeurige code uit te voeren en vervolgens een bootkit in de Windows-kernel tijdens het opstarten zou kunnen injecteren. Microsoft deed dit door een Windows-update uit te voeren die de SBAT-variabele bijwerkte, waarin stond dat kwetsbare GRUB-versies niet op deze systemen mochten opstarten. De door de distributie geleverde shim-bootloader las deze variabele, las de SBAT-sectie van de geĆÆnstalleerde GRUB-kopie, begreep dat ze conflicteerden en weigerde om grub te laden met de melding "Er is iets helemaal mis gegaan". Deze update had niet toegepast moeten worden op systemen met dual-boot, maar werd dat toch.
Samenvattend:
1) Microsoft paste de update toe op systemen waar deze niet op toegepast had moeten worden.
2) Sommige Linux-distributies hebben de GRUB-bootloader en de SBAT-beveiligingsgeneratie niet bijgewerkt, toen kwetsbaarheden in GRUB werden ontdekt.
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.
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.
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.
Bron: opennet.ru
