En giltig signatur slutade betyda säker kod
Secure Boot gjorde precis det den byggdes för, och det var problemet. Den 14 juli publicerade säkerhetsföretaget ESET forskning, ledd av Martin Smolar, som visar elva Microsoft-signerade bootloaders, alla i version 0.9 eller lägre, som en maskin villigt kör eftersom signaturen är äkta. Koden bakom den signaturen är ett decennium gammal och trasig, men Secure Boot kontrollerar undertecknaren, inte säkerheten hos det som signerades.
Resultatet är en angripare som kan köra overifierad kod vid start på nästan varje UEFI-dator. ESET rapporterade fyndet till samordningscentret CERT/CC i februari, och Microsoft lade till alla elva filer på sin återkallelselista den 9 juni. Glappet mellan en betrodd signatur och pålitlig kod är hela historien, och det täcks inte av patchen ensam.
Så fungerar kringgåendet
Angriparen bryter inte upp något; han levererar något som redan är betrott. De flesta UEFI-system bär Microsofts tredjepartscertifikat, Microsoft Corporation UEFI CA 2011, i sin lista över tillåtna undertecknare. En angripare kopierar en av de gamla signerade bootloaders till EFI-systempartitionen, diskens lilla startområde, och firmwaren accepterar den eftersom signaturen leder tillbaka till det betrodda certifikatet. Inga administratörsrättigheter behövs, bara förmågan att skriva den filen.
Därifrån gör tre gamla luckor jobbet. Bootloaders litar på föråldrad GRUB 2-kod med ett fel från 2015 som kör overifierade moduler; versioner under 0.9 saknar återkallelselistan som skulle blockera kända dåliga certifikat; och versioner före 15.3 ignorerar SBAT, den nyare mekanismen som ska fasa ut sårbara binärer. Registrerad som CVE-2026-8863 och CVE-2026-10797 slutar kedjan med att angriparens kod körs innan operativsystemet laddas, den idealiska platsen att gömma sig på.
Varför patchen är den lätta delen
En återkallelse skyddar bara en maskin som faktiskt tog emot den. Microsofts fix den 9 juni lägger de elva filerna till dbx, firmwarens spärrlista, och på hanterade Windows-flottor går den uppdateringen via de normala kanalerna. Haken är att många organisationer medvetet håller tillbaka ändringar i firmwarens spärrlista, eftersom en felaktig dbx-post kan lämna en enhet oförmögen att starta, och den risken är högre på äldre eller dual-boot-hårdvara. Återkallelsen finns; om den nått dina maskiner är en annan fråga.
Det djupare problemet är att räkna. Det offentliga shim-review-registret började först 2017, och det finns ingen jämförbar lista över vad som signerades dessförinnan, så ingen kan med säkerhet säga hur många gamla, fortfarande betrodda bootloaders som är ute. Elva är talet ESET kunde namnge, inte talet som finns. En kontroll som beror på att känna varje betrodd undertecknare är svag precis där inventeringen tar slut.
Vad som verkligen bör kontrolleras denna vecka
Behandla detta som en uppgift i återkallelsehygien, inte som en enda patch. Bekräfta att dbx-uppdateringen från den 9 juni verkligen tillämpades över hela parken i stället för att anta det; ESET hänvisar till granskningsverktyg och PowerShell-kontroller som rapporterar det aktuella återkallelseläget. Utvidga kontrollen bortom Windows, för Linux-servrar och apparater får samma fix via Linux Vendor Firmware Service, och dual-boot-bärbara är den klassiska blinda fläcken.
För europeiska operatörer är ramen nu lika mycket regulatorisk som teknisk. Under NIS2 faller startkedjans integritet inom de säkerhetsåtgärder en väsentlig entitet förväntas visa, och ett firmware-bootkit är precis den sortens beständighet en tillsynsmyndighet frågar om efter en incident. Ägarens åtgärd är lätt att formulera och lätt att hoppa över: verifiera vad din firmware fortfarande litar på, och bevisa att spärren landade.
Läs vidare: 570 Windows-rättningar på en dag, två utnyttjas redan | En 18 år gammal Cisco-lucka har nu 3 dagars frist
