APIC/EPIC! Intel-brikker lekker hemmeligheter selv kjernen ikke burde se...

Her er denne ukens BWAIN, vår morsomme betegnelse for en Feil med et imponerende navn.

BWAIN er en utmerkelse som vi deler ut når en ny cybersikkerhetsfeil ikke bare viser seg å være interessant og viktig, men også dukker opp med sin egen logo, domenenavn og nettside.

Denne er dubbet ÆPIC-lekkasje, et ordspill på ordene APIC og EPIC.

Førstnevnte er forkortelse for Avansert programmerbar avbruddskontroller, og sistnevnte er ganske enkelt ordet "episk", som i giganten, massive, ekstrem, mega, humongøs.

Bokstaven Æ har ikke blitt brukt i skriftlig engelsk siden saksisk tid. Navnet dens er æsc, uttales ash (som i treet), og det representerer ganske mye lyden av A i det moderne ordet ASH. Men vi antar at du skal uttale ordet ÆPIC her enten som "APIC-slash-EPIC", eller som "ah!-eh?-PIC".

Hva handler det om?

Alt dette reiser fem fascinerende spørsmål:

• Hva er en APIC, og hvorfor trenger jeg det?
• Hvordan kan du ha data som til og med kjernen kan du ikke kikke på?
• Hva forårsaker denne episke feilen i APIC?
• Har ÆPIC-lekkasje påvirke meg?
• Hva du skal gjøre om det?

Hva er en APIC?

La oss spole tilbake til 1981, da IBM PC-en først dukket opp.

PC-en inkluderte en brikke kalt Intel 8259A programmerbar avbruddskontroller, eller PIC. (Senere modeller, fra PC AT og utover, hadde to PIC-er, lenket sammen, for å støtte flere avbruddshendelser.)

Hensikten med PIC var bokstavelig talt å avbryte programmet som kjører på PC-ens sentrale prosessor (CPU) hver gang noe tidskritisk fant sted som trengte oppmerksomhet med en gang.

Disse maskinvareavbruddene inkluderte hendelser som: tastaturet får et tastetrykk; serieporten mottar et tegn; og en gjentatt maskinvare-timer som tikker over.

Uten et maskinvareavbruddssystem av denne typen, ville operativsystemet måtte være overfylt med funksjonskall for å se etter innkommende tastetrykk med jevne mellomrom, noe som ville være sløsing med CPU-kraft når ingen skrev, men ville ikke reagere. nok når de gjorde det.

Som du kan forestille deg, ble PIC snart fulgt av en oppgradert chip kalt APIC, En avansert slags PIC innebygd i selve CPUen.

I disse dager gir APIC-er mye mer enn bare tilbakemelding fra tastaturet, serieporten og systemtimeren.

APIC-hendelser utløses av (og gir sanntidsdata om) hendelser som overoppheting, og tillater maskinvareinteraksjon mellom de forskjellige kjernene i moderne flerkjerneprosessorer.

Og dagens Intel-brikker kan, om vi kan forenkle, generelt konfigureres til å fungere på to forskjellige måter, kjent som xAPIC-modus og x2APIC-modus.

Her xAPIC er den "legacy" måten å trekke ut data fra avbruddskontrolløren, og x2APIC er den mer moderne måten.

For å forenkle enda mer, er xAPIC avhengig av det som kalles MMIO, kort for minnetilordnet inngang/utgang, for å lese data ut av APIC når den registrerer en hendelse av interesse.

I MMIO-modus kan du finne ut hva som utløste en APIC-hendelse ved å lese fra et spesifikt minneområde (RAM), som speiler inngangs-/utgangsregistrene til selve APIC-brikken.

Disse xAPIC-dataene er kartlagt til en 4096-byte minneblokk et sted i den fysiske RAM-en til datamaskinen.

Dette forenkler tilgangen til dataene, men det krever en irriterende, kompleks (og, som vi skal se, potensielt farlig) interaksjon mellom APIC-brikken og systemminnet.

Derimot krever x2APIC at du gjør det les ut APIC-dataene direkte fra selve brikken, ved å bruke det som kalles Modellspesifikke registre (MSR).

Ifølge Intel unngår MMIO-delen av prosessen "gir betydelig økt prosessoradresserbarhet og noen forbedringer ved avbruddslevering."

Spesielt betyr å trekke ut APIC-dataene direkte fra registrene på brikken at den totale mengden data som støttes, og det maksimale antallet CPU-kjerner som kan administreres samtidig, ikke er begrenset til de 4096 bytene som er tilgjengelige i MMIO-modus.

Hvordan kan du ha data som ikke engang kjernen kan se på?

Du har sikkert allerede gjettet at dataene som havner i MMIO-minneområdet når du bruker xAPIC-modus ikke alltid er så nøye administrert som det burde være...

…og dermed at en slags "datalekkasje" inn i det MMIO-området er hjertet av dette problemet.

Men gitt at du trenger allerede krefter på sysadmin-nivå å lese MMIO-dataene i utgangspunktet, og derfor kan du nesten helt sikkert få tak i alle data i minnet uansett...

…hvorfor skulle andres data ved en feiltakelse i APIC MMIO-dataområdet representere en episk lekke?

Det kan gjøre noen typer datastjeling eller RAM-skraping-angrep litt lettere i praksis, men det ville sikkert ikke gi deg noen mer minnesnoking-evne enn du allerede hadde i teorien?

Dessverre stemmer ikke denne antagelsen hvis noen programvare på systemet bruker Intels SGX, en forkortelse for Software Guard -utvidelser.

---

LÆR MER OM SGX

---

SGX støttes av mange nyere Intel-CPUer, og det gir en måte for operativsystemkjernen å "forsegle" en del av kode og data i en fysisk blokk med RAM for å danne det som er kjent som en enklave.

Dette gjør at den oppfører seg, i det minste midlertidig, omtrent som de spesielle sikkerhetsbrikkene i mobiltelefoner som brukes til å lagre hemmeligheter som dekrypteringsnøkler.

Når enklavens SGX "lås" er satt, kan bare programkoden som kjører inne i det forseglede minneområdet lese og skrive innholdet i den RAM-en.

Som et resultat er de interne detaljene i alle beregninger som skjer etter at enklaven er aktivert, usynlige for andre koder, tråder, prosesser eller brukere i systemet.

Inkludert selve kjernen.

Det er en måte å kalle koden som er forseglet inn i enklaven, og en måte for den å returnere utdata fra beregningene den kan utføre, men det er ingen måte å gjenopprette, eller spionere på, eller feilsøke, koden og tilhørende data mens den kjører.

Enklaven blir effektivt til en svart boks som du kan mate innganger til, for eksempel en data som skal signeres med en privat nøkkel, og trekke ut utganger, for eksempel den digitale signaturen som genereres, men som du ikke kan vinkle ut kryptonøklene fra brukt i signeringsprosessen.

Som du kan forestille deg, hvis data som er ment å være forseglet inne i en SGX-enklave ved et uhell skulle bli duplisert inn i MMIO RAM-en som brukes til å "speile" APIC-dataene når du bruker xAPIC "minnetilordnet"-modus ...

…som vil bryte sikkerheten til SGX, som sier at ingen data skal komme ut av en SGX-enklave etter at den er opprettet, med mindre den bevisst er eksportert av kode som allerede kjører inne i selve enklaven.

Hva forårsaker denne episke feilen i APIC?

Forskerne bak ÆPIC Lekkasjepapir oppdaget at ved å ordne med å lese ut APIC-data via en utspekulert og uvanlig sekvens av minnetilganger ...

…de kunne lure prosessoren til å fylle opp APIC MMIO-plassen, ikke bare med data som nylig er mottatt fra APIC selv, men også med data som tilfeldigvis ble brukt av CPU nylig til et annet formål.

Denne oppførselen er en bieffekt av det faktum at selv om APIC MMIO-minnesiden er 4096 byte stor, produserer ikke APIC-brikken i xAPIC-modus faktisk 4096 byte med data, og CPU-en nøytraliserer ikke alltid riktig. de ubrukte delene av MMIO-regionen ved å fylle den med nuller først.

I stedet ble gamle data som ble til overs i CPU-cachen skrevet ut sammen med de nye dataene mottatt fra selve APIC-brikken.

Som forskerne sa det, koker feilen ned til det som er kjent som en uinitialisert minnelesing, der du ved et uhell gjenbruker andres data i RAM fordi verken de eller du fjernet det fra tidligere hemmeligheter først.

Påvirker ÆPIC-lekkasjen meg?

For en fullstendig liste over berørte sjetonger, se Intels egen rådgivning.

Så vidt vi kan se, hvis du har en 10. eller 11. generasjons Intel-prosessor, er du sannsynligvis berørt.

Men hvis du har en splitter ny 12. generasjons CPU (den aller siste i skrivende stund), så ser det ut til at bare serverklasse-brikker er berørt.

Ironisk nok, i 12. generasjons bærbare brikker, har Intel gitt opp SGX, så denne feilen gjelder ikke fordi det er umulig å ha noen "forseglede" SGX-enklaver som kan lekke.

Selvsagt, selv på en potensielt sårbar brikke, hvis du ikke er avhengig av programvare som bruker SGX, gjelder heller ikke feilen.

Og feilen, kalt CVE-2022-21233, kan bare utnyttes av en angriper som allerede har lokal tilgang på admin-nivå (root) til datamaskinen din.

Vanlige brukere kan ikke få tilgang til APIC MMIO-datablokken, og har derfor ingen mulighet til å se på noe i det hele tatt der inne, enn si hemmelige data som kan ha lekket ut fra en SGX-enklave.

Også virtuelle gjestemaskiner (VM-er) som kjører under kontroll av et vertsoperativsystem i en hypervisor som HyperV, VMWare eller VirtualBox kan nesten helt sikkert ikke bruke dette trikset til å plyndre hemmeligheter fra andre gjester eller verten selv.

Det er fordi gjeste-VM-er generelt ikke får tilgang til de virkelige APIC-kretsene i vertsprosessoren; i stedet får hver gjest sin egen simulerte APIC som er unik for den virtuelle maskinen.

Hva gjør jeg?

Ikke få panikk.

På en bærbar eller stasjonær datamaskin er du kanskje ikke i faresonen i det hele tatt, enten fordi du har en eldre (eller, heldigvis, en helt ny!) datamaskin, eller fordi du ikke er avhengig av SGX uansett.

Og selv om du er risikofylt, har sannsynligvis alle som kommer inn på den bærbare datamaskinen din som admin/root nok kraft til å forårsake en verden av problemer allerede.

Hvis du har sårbare servere og du er avhengig av SGX som en del av din operasjonelle sikkerhet, sjekk Intels sikkerhetsrådgivning INTEL-SA-00657 for beskyttelse og avbøtende informasjon.

Ifølge forskerne som skrev dette opp, "Intel [har] gitt ut oppdateringer av mikrokode og SGX Software Development Kit for å fikse problemet."

Linux-kjerneteamet ser også ut til å jobbe akkurat nå med en oppdatering som lar deg konfigurere systemet ditt slik at det alltid vil bruke x2APIC (som, som du vil huske fra tidligere, ikke overfører APIC-data via delt minne), og vil grasiøst forhindre at systemet tvinges tilbake til xAPIC-modus etter oppstart.

---