Elleve glemte oppstartsfiler lar angripere gå rundt Secure Boot

ESET publiserte 14. juli 2026 funnet av elleve gamle oppstartslastere som Microsoft har signert, og som fortsatt var tiltrodd. Alle er såkalte shimer i versjon 0.9 eller eldre, og de kan brukes til å omgå Secure Boot på maskiner der Microsofts tredjepartssertifikat er innrullert. Microsoft trakk dem tilbake 9. juni 2026, i sikkerhetsvarselet for CVE-2026-8863, som selskapet graderte som viktig med CVSS 7.8. Funnet er gjort av ESET-forskeren Martin Smolár, og CERT/CC har utstedt et eget varsel.

Hva som skjer teknisk

En shim er et lite førstetrinns oppstartsprogram som Microsoft signerer én gang, og som deretter fungerer som et eget tillitsanker videre i oppstarten. Ordningen finnes fordi hver Linux-distribusjon bygger sine egne oppstartsfiler, og det ville vært upraktisk å få hver enkelt av dem signert direkte. Tillitskjeden går i tre ledd: fastvaren kontrollerer shimen mot Microsoft-sertifikatet, shimen kontrollerer neste ledd mot sitt eget innebygde leverandørsertifikat, og det leddet kontrollerer kjernen mot det samme. Svakheten er at en gammel shim fortsatt godtas av fastvaren. Angriperen trenger ikke ha den aktuelle distribusjonen installert i det hele tatt, og kan ta med sin egen kopi av den gamle filen og legge den på maskinens oppstartspartisjon.

ESET beskriver fire veier videre. Gamle shimer stoler fortsatt på andretrinnslastere med kjente hull, blant annet en GRUB 2-fil rammet av CVE-2015-5281. Shimer eldre enn versjon 0.9 håndhever bare tillatelseslisten for egne signeringsnøkler, ikke sperrelisten, slik at en virksomhet som trodde den hadde sperret en gammel nøkkel ikke hadde det. Støtte for den versjonsbaserte tilbakekallingen SBAT kom først i shim-versjon 15.3, så samtlige av de rapporterte filene ignorerer den ordningen fullstendig. I tillegg fant ESET én ny feil, CVE-2026-10797, der signaturlengden leses fra to ulike steder slik at selve tilbakekallingssjekken kan lures. Det nummeret er brukt av ESET og CERT/CC, men er per 18. august 2026 ikke publisert i NVD eller i CVE-registeret. Konsekvensen er at kode kan kjøres før operativsystemet starter, og dermed overleve både reinstallasjon og bytte av harddisk. Angrepet krever lokale administratorrettigheter eller fysisk tilgang, ifølge Microsoft. Ingen av kildene melder om observert utnyttelse, og ESET har med hensikt latt være å publisere indikatorer. Merk også et sprik: Ars Technica oppgir CVE-2015-5381 for GRUB 2-hullet, mens ESET oppgir CVE-2015-5281, og det er sistnevnte som faktisk er en Secure Boot-omgåelse.

Hva det betyr for deg som drifter Linux-maskiner

Windows-maskiner får denne tilbakekallingen automatisk. Det gjør ikke Linux-maskinene dine. De må hente den oppdaterte sperrelisten selv, og ESET peker på Linux Vendor Firmware Service som veien. Vår vurdering er at dette er den praktiske skillelinjen i saken, og at den treffer akkurat de maskinene som sjelden står øverst på noen liste: byggetjenere, laboratoriemaskiner, utstyr på ubemannede steder og alt som er satt opp en gang og siden fungert. Kravet om lokal administratortilgang eller fysisk tilgang gjør ikke dette til en teoretisk øvelse. Kortvarig fysisk tilgang til en avslått maskin er nettopp det Secure Boot er ment å beskytte mot.

Det ubehagelige spørsmålet er hvor mange slike filer som fortsatt finnes. Ingen vet, og innsyn i signeringsordningen kom først i 2017. Tilbakekalling basert på filsignaturer skalerer dårlig, fordi listen har rundt 32 kilobyte plass, og det er nettopp derfor de versjonsbaserte ordningene ble laget. Har du ansvar for maskiner som håndteres av andre, for eksempel ved avhending eller service, er det verdt å merke seg at to av de berørte produktene er nettopp slette- og diagnoseverktøy. Og en advarsel før du setter i gang: CERT/CC skriver at oppdatering av sperrelisten kan gjøre maskiner ustartbare, og at rekkefølgen betyr noe. Oppdater tillatelseslisten før sperrelisten.

Berigo anbefaler

• Rull ut den oppdaterte sperrelisten på Linux-maskinene deres. Windows får den automatisk, Linux gjør det ikke.
• Test på noen få maskiner først. CERT/CC advarer om at oppdateringen kan gjøre maskiner ustartbare, og at tillatelseslisten skal oppdateres før sperrelisten.
• Sjekk om Secure Boot i det hele tatt er slått på i parken deres, og om Microsofts tredjepartssertifikat er innrullert.
• Ta med maskiner som er fysisk eksponert i vurderingen: bærbare på reise, utstyr på ubemannede lokasjoner og maskiner som er inne til service eller avhending.
• Husk at et kompromiss på dette nivået overlever reinstallasjon. Gjenoppretting av en slik maskin er en fastvaresak, ikke en operativsystemsak.