En gyldig signatur holdt op med at betyde sikker kode
Secure Boot gjorde præcis det, den var bygget til, og det var problemet. Den 14. juli offentliggjorde sikkerhedsfirmaet ESET forskning, ledet af Martin Smolar, der viser elleve Microsoft-signerede bootloadere, alle i version 0.9 eller lavere, som en maskine villigt kører, fordi signaturen er ægte. Koden bag den signatur er ti år gammel og fejlbehæftet, men Secure Boot kontrollerer underskriveren, ikke sikkerheden af det, der blev signeret.
Resultatet er en angriber, der kan køre ikke-verificeret kode ved opstart på næsten enhver UEFI-computer. ESET rapporterede fundet til koordinationscentret CERT/CC i februar, og Microsoft tilføjede alle elleve filer til sin tilbagekaldelsesliste den 9. juni. Kløften mellem en betroet signatur og pålidelig kode er hele historien, og den lukkes ikke af patchen alene.
Sådan fungerer omgåelsen
Angriberen bryder ikke noget op; han leverer noget, der allerede er betroet. De fleste UEFI-systemer bærer Microsofts tredjepartscertifikat, Microsoft Corporation UEFI CA 2011, i deres liste over tilladte underskrivere. En angriber kopierer en af de gamle signerede bootloadere til EFI-systempartitionen, diskens lille startområde, og firmwaren accepterer den, fordi signaturen fører tilbage til det betroede certifikat. Der kræves ingen administratorrettigheder, kun evnen til at skrive den fil.
Derfra gør tre gamle huller arbejdet. Bootloaderne stoler på forældet GRUB 2-kode med en fejl fra 2015, der kører ikke-verificerede moduler; versioner under 0.9 mangler den tilbagekaldelsesliste, der ville blokere kendte dårlige certifikater; og versioner før 15.3 ignorerer SBAT, den nyere mekanisme, der skal udfase sårbare binærfiler. Registreret som CVE-2026-8863 og CVE-2026-10797 slutter kæden med, at angriberens kode kører, før styresystemet indlæses, det ideelle sted at gemme sig.
Hvorfor patchen er den nemme del
En tilbagekaldelse beskytter kun en maskine, der faktisk modtog den. Microsofts rettelse den 9. juni tilføjer de elleve filer til dbx, firmwarens spærreliste, og på administrerede Windows-flåder løber den opdatering via de normale kanaler. Haken er, at mange organisationer bevidst holder ændringer i firmwarens spærreliste tilbage, fordi en forkert dbx-post kan efterlade en enhed ude af stand til at starte, og den risiko er højere på ældre eller dual-boot-hardware. Tilbagekaldelsen findes; om den nåede dine maskiner er et andet spørgsmål.
Det dybere problem er at tælle. Det offentlige shim-review-register begyndte først i 2017, og der findes ingen tilsvarende liste over, hvad der blev signeret før da, så ingen kan sige med sikkerhed, hvor mange gamle, stadig betroede bootloadere der er derude. Elleve er det tal, ESET kunne navngive, ikke det tal, der findes. En kontrol, der afhænger af at kende hver betroet underskriver, er svag netop der, hvor fortegnelsen slipper op.
Hvad der reelt skal tjekkes i denne uge
Behandl det som en opgave i tilbagekaldelseshygiejne, ikke som en enkelt patch. Bekræft, at dbx-opdateringen fra den 9. juni faktisk blev anvendt på tværs af parken, i stedet for at antage det; ESET henviser til revisionsværktøjer og PowerShell-tjek, der rapporterer den aktuelle tilbagekaldelsesstatus. Udvid tjekket ud over Windows, for Linux-servere og apparater får den samme rettelse via Linux Vendor Firmware Service, og dual-boot-bærbare er den klassiske blinde vinkel.
For europæiske operatører er rammen nu lige så meget regulatorisk som teknisk. Under NIS2 falder startkædens integritet ind under de sikkerhedsforanstaltninger, en væsentlig enhed forventes at demonstrere, og et firmware-bootkit er præcis den slags persistens, en tilsynsmyndighed vil spørge til efter en hændelse. Ejerens handling er nem at sige og nem at springe over: verificer, hvad din firmware stadig stoler på, og bevis, at blokeringen landede.
Læs videre: 570 Windows-rettelser på én dag, to udnyttes allerede | En 18 år gammel Cisco-fejl har nu 3 dages frist
