APIC/EPIC! Intel-chips lækker hemmeligheder, selv kernen ikke burde se...

Her er denne uges BWAIN, vores sjove betegnelse for en Bug med et imponerende navn.

BWAIN er en anerkendelse, som vi uddeler, når en ny cybersikkerhedsfejl ikke kun viser sig at være interessant og vigtig, men også dukker op med sit eget logo, domænenavn og hjemmeside.

Denne er døbt ÆPIC Lækage, et ordspil på ordene APIC , EPIC.

Førstnævnte er en forkortelse for Avanceret programmerbar interruptcontroller, og sidstnævnte er simpelthen ordet "episk", som i kæmpe, massive, ekstrem, Mega, kæmpestor.

Bogstavet Æ er ikke blevet brugt i skriftlig engelsk siden saksisk tid. Dens navn er æsc, udtalt aske (som i træet), og det repræsenterer stort set lyden af ​​A'et i det moderne ord ASH. Men vi antager, at du skal udtale ordet ÆPIC her enten som "APIC-skråstreg-EPIC", eller som "ah!-eh?-PIC".

Hvad handler det om?

Alt dette rejser fem fascinerende spørgsmål:

• Hvad er en APIC, og hvorfor har jeg brug for det?
• Hvordan kan du have data der selv kernen kan du ikke kigge på?
• Hvad forårsager denne episke fiasko i APIC?
• Er ÆPIC Lækage påvirke mig?
• Hvad skal man gøre om det?

Hvad er en APIC?

Lad os spole tilbage til 1981, hvor IBM PC'en først dukkede op.

Pc'en inkluderede en chip kaldet Intel 8259A programmerbar interrupt controllereller PIC. (Senere modeller, fra PC AT og fremefter, havde to PIC'er, kædet sammen, for at understøtte flere afbrudte begivenheder.)

Formålet med PIC'en var bogstaveligt talt at afbryde programmet, der kørte på pc'ens centrale processor (CPU), hver gang noget tidskritisk fandt sted, som trængte til opmærksomhed med det samme.

Disse hardwareafbrydelser inkluderede begivenheder såsom: tastaturet fik et tastetryk; den serielle port modtager et tegn; og en gentagende hardware-timer, der tikker over.

Uden et hardware-afbrydelsessystem af denne art, ville operativsystemet skulle være fyldt med funktionskald for at tjekke for indgående tastetryk på en regelmæssig basis, hvilket ville være spild af CPU-kraft, når ingen skrev, men ville ikke reagere. nok da de gjorde det.

Som du kan forestille dig, blev PIC'en snart efterfulgt af en opgraderet chip kaldet APIC, en fremskreden en slags PIC indbygget i selve CPU'en.

I disse dage giver APIC'er meget mere end blot feedback fra tastaturet, den serielle port og systemtimeren.

APIC-hændelser udløses af (og giver realtidsdata om) hændelser såsom overophedning og tillader hardwareinteraktion mellem de forskellige kerner i moderne multicore-processorer.

Og nutidens Intel-chips, hvis vi forenklet må meget, kan generelt konfigureres til at fungere på to forskellige måder, kendt som xAPIC-tilstand , x2APIC-tilstand.

Her, xAPIC er den "legacy" måde at udtrække data fra interrupt-controlleren, og x2APIC er den mere moderne måde.

For at forenkle endnu mere, er xAPIC afhængig af det, der hedder MMIO, forkortelse for hukommelseskortlagt input/output, for at læse data ud af APIC'en, når den registrerer en begivenhed af interesse.

I MMIO-tilstand kan du finde ud af, hvad der udløste en APIC-hændelse, ved at læse fra en specifik region af hukommelsen (RAM), som afspejler input/output-registrene på selve APIC-chippen.

Disse xAPIC-data er kortlagt i en 4096-byte hukommelsesblok et eller andet sted i computerens fysiske RAM.

Dette forenkler adgangen til dataene, men det kræver en irriterende, kompleks (og, som vi skal se, potentielt farlig) interaktion mellem APIC-chippen og systemhukommelsen.

I modsætning hertil kræver x2APIC, at du gør det læse APIC-dataene direkte fra selve chippen ved hjælp af det, der er kendt som Modelspecifikke registre (MSR'er).

Ifølge Intel undgår man MMIO-delen af ​​processen "giver betydeligt øget processoradresserbarhed og nogle forbedringer ved afbrydelse af levering."

Navnlig betyder udtrækning af APIC-data direkte fra on-chip-registre, at den samlede mængde understøttede data og det maksimale antal CPU-kerner, der kan administreres på samme tid, ikke er begrænset til de 4096 bytes, der er tilgængelige i MMIO-tilstand.

Hvordan kan du have data, som selv kernen ikke kan kigge på?

Du har sikkert allerede gættet, at de data, der ender i MMIO-hukommelsesområdet, når du bruger xAPIC-tilstand, ikke altid administreres så omhyggeligt, som det burde være...

…og dermed er en form for "datalæk" ind i det MMIO-område kernen i dette problem.

Men givet det dig har allerede brug for beføjelser på sysadmin-niveau at læse MMIO-dataene i første omgang, og derfor kan du næsten helt sikkert få alle data i hukommelsen alligevel...

…hvorfor ville det at have andres data vist ved en fejltagelse i APIC MMIO-dataområdet repræsentere en episk lække?

Det kan måske gøre nogle typer af datatyveri eller RAM-skrabeangreb lidt nemmere i praksis, men det ville sikkert ikke give dig mere hukommelsessnooping, som du allerede havde i teorien?

Desværre er denne antagelse ikke sand, hvis nogen software på systemet bruger Intels SGX, en forkortelse for Software Guard-udvidelser.

---

LÆS MERE OM SGX

---

SGX er understøttet af mange nyere Intel-CPU'er, og det giver en måde for operativsystemkernen at "forsegle" en del kode og data i en fysisk blok af RAM for at danne det, der er kendt som en enklave.

Dette gør, at den i det mindste midlertidigt opfører sig meget som de særlige sikkerhedschips i mobiltelefoner, der bruges til at gemme hemmeligheder såsom dekrypteringsnøgler.

Når først enklavens SGX "lås" er indstillet, er det kun programkoden, der kører inde i det forseglede hukommelsesområde, der kan læse og skrive indholdet af den RAM.

Som et resultat heraf er de interne detaljer i alle beregninger, der sker, efter at enklaven er aktiveret, usynlige for enhver anden kode, tråd, proces eller bruger på systemet.

Inklusiv selve kernen.

Der er en måde at kalde koden, der er blevet forseglet ind i enklaven, og en måde for den at returnere output fra de beregninger, den kan udføre, men der er ingen måde at gendanne eller spionere på eller fejlsøge koden og dens tilknyttede data, mens den kører.

Enklaven bliver effektivt til en sort boks, hvortil du kan føre input, såsom data, der skal signeres med en privat nøgle, og udtrække output, såsom den genererede digitale signatur, men hvorfra du ikke kan blinke de kryptografiske nøgler ud. brugt i underskriftsprocessen.

Som du kan forestille dig, hvis data, der formodes at være forseglet inde i en SGX-enklave, nogensinde ved et uheld skulle blive duplikeret i MMIO RAM, der bruges til at "spejle" APIC-dataene, når du bruger xAPIC "memory-mapped"-tilstand...

…det ville krænke SGX's sikkerhed, som siger, at ingen data nogensinde må komme ud af en SGX-enklave, efter at den er blevet oprettet, medmindre den bevidst er eksporteret af kode, der allerede kører inde i selve enklaven.

Hvad forårsager denne episke fejl i APIC?

Forskerne bag ÆPIC Lækagepapir opdagede, at ved at arrangere at læse APIC-data via en snedig og usædvanlig sekvens af hukommelsesadgange...

…de kunne narre processoren til at fylde APIC MMIO-pladsen op, ikke kun med data, der er frisk modtaget fra selve APIC'en, men også med data, der tilfældigvis er blevet brugt af CPU'en for nylig til et andet formål.

Denne adfærd er en bivirkning af det faktum, at selvom APIC MMIO-hukommelsessiden er 4096 bytes stor, producerer APIC-chippen i xAPIC-tilstand faktisk ikke 4096 bytes' data, og CPU'en neutraliserer ikke altid korrekt. de ubrugte dele af MMIO-regionen ved at udfylde den med nuller først.

I stedet blev gamle data tilbage i CPU-cachen skrevet ud sammen med de nye data modtaget fra selve APIC-chippen.

Som forskerne udtrykte det, koger fejlen ned til det, der er kendt som en uinitialiseret hukommelseslæsning, hvor du ved et uheld genbruger en andens efterladte data i RAM, fordi hverken de eller du fjernede det fra dets tidligere hemmeligheder først.

Påvirker ÆPIC-lækagen mig?

For en komplet liste over berørte chips, se Intels egen rådgivning.

Så vidt vi kan se, er du sandsynligvis berørt, hvis du har en 10. eller 11. generation af Intel-processor.

Men hvis du har en helt ny 12. generations CPU (den allerseneste i skrivende stund), så ser det ud til, at det kun er chips i serverklassen, der er berørt.

Ironisk nok har Intel i 12. generations bærbare chips givet op på SGX, så denne fejl gælder ikke, fordi det er umuligt at have nogen "forseglede" SGX-enklaver, der kan lække.

Selvfølgelig, selv på en potentielt sårbar chip, hvis du ikke er afhængig af nogen software, der bruger SGX, så gælder fejlen heller ikke.

Og fejlen, døbt CVE-2022-21233, kan kun udnyttes af en angriber, der allerede har lokal adgang på adminniveau (root) til din computer.

Faste brugere kan ikke få adgang til APIC MMIO-datablokken, og har derfor ingen mulighed for at kigge på noget som helst derinde, endsige hemmelige data, der kunne være sivet ud fra en SGX-enklave.

Således, virtuelle gæstemaskiner (VM'er), der kører under kontrol af et værtsoperativsystem i en hypervisor som HyperV, VMWare eller VirtualBox, kan næsten med sikkerhed ikke bruge dette trick til at plyndre hemmeligheder fra andre gæster eller værten selv.

Det skyldes, at gæste-VM'er generelt ikke får adgang til det rigtige APIC-kredsløb i værtsprocessoren; i stedet får hver gæst sin egen simulerede APIC, der er unik for den pågældende VM.

Hvad skal jeg gøre?

Gå ikke i panik.

På en bærbar eller stationær computer er du måske slet ikke i fare, enten fordi du har en ældre (eller heldigvis en helt ny!) computer, eller fordi du alligevel ikke er afhængig af SGX.

Og selvom du er en risiko, har enhver, der kommer ind på din bærbare computer som admin/root, sandsynligvis nok strøm til at give dig en verden af ​​problemer allerede.

Hvis du har sårbare servere, og du er afhængig af SGX som en del af din operationelle sikkerhed, skal du tjekke Intels sikkerhedsrådgivning INTEL-SA-00657 for information om beskyttelse og afbødning.

Ifølge forskerne, der skrev dette op, "Intel [har] udgivet opdateringer til mikrokode og SGX Software Development Kit for at løse problemet."

Linux-kerneteamet ser også ud til at arbejde lige nu på en patch, der giver dig mulighed for at konfigurere dit system, så det altid vil bruge x2APIC (som, som du vil huske fra tidligere, ikke transmitterer APIC-data via delt hukommelse). og vil yndefuldt forhindre, at systemet tvinges tilbage til xAPIC-tilstand efter opstart.

---