APIC/EPIC! Intel-chips lekken geheimen die zelfs de kernel niet mag zien...

Hier is de BWAIN van deze week, onze grappige term voor a Bug met een indrukwekkende naam.

BWAIN is een onderscheiding die we uitdelen wanneer een nieuwe cybersecurity-fout niet alleen interessant en belangrijk blijkt te zijn, maar ook opduikt met een eigen logo, domeinnaam en website.

Deze is nagesynchroniseerd (PIC-lek), een woordspeling op de woorden APIC en EPIC.

De eerste is een afkorting voor Geavanceerde programmeerbare interruptcontroller, en de laatste is gewoon het woord "episch", zoals in reus, massief, extreem, mega, gigantisch.

De letter Æ is sinds de Saksische tijd niet meer in geschreven Engels gebruikt. Zijn naam is sc, uitgesproken as (zoals in de boom), en het vertegenwoordigt vrijwel het geluid van de A in het moderne woord ASH. Maar we gaan ervan uit dat je het woord moet uitspreken PIC hier ofwel als "APIC-slash-EPIC", of als "ah!-eh?-PIC".

Waar gaat het over?

Dit alles roept vijf fascinerende vragen op:

• Wat is een APIC, en waarom heb ik het nodig?
• Hoe kun je gegevens hebben die? zelfs de kernel niet kunnen kijken?
• Wat veroorzaakt deze epische mislukking? bij APIC?
• Heeft het (PIC-lek) heeft effect op mij?
• Wat te doen over het?

Wat is een APIC?

Laten we terugspoelen naar 1981, toen de IBM PC voor het eerst verscheen.

De pc bevatte een chip genaamd de Intel 8259A programmeerbare onderbrekingscontroller, of PIC. (Latere modellen, vanaf de PC AT, hadden twee PIC's, aan elkaar geketend, om meer interruptgebeurtenissen te ondersteunen.)

Het doel van de PIC was letterlijk om het programma op de centrale processor (CPU) van de pc te onderbreken wanneer er iets tijdkritisch gebeurde dat onmiddellijk aandacht nodig had.

Deze hardware-interrupts omvatten gebeurtenissen zoals: het toetsenbord dat een toetsaanslag krijgt; de seriële poort die een teken ontvangt; en een herhalende hardware-timer die tikt.

Zonder een dergelijk hardware-onderbrekingssysteem zou het besturingssysteem bezaaid moeten zijn met functieaanroepen om regelmatig te controleren op inkomende toetsaanslagen, wat een verspilling van CPU-kracht zou zijn als niemand aan het typen was, maar niet zou reageren genoeg als ze dat deden.

Zoals je je kunt voorstellen, werd de PIC al snel gevolgd door een verbeterde chip genaamd de APICeen vergevorderd soort PIC ingebouwd in de CPU zelf.

Tegenwoordig bieden APIC's veel meer dan alleen feedback van het toetsenbord, de seriële poort en de systeemtimer.

APIC-gebeurtenissen worden geactiveerd door (en bieden realtime gegevens over) gebeurtenissen zoals oververhitting, en maken hardware-interactie tussen de verschillende kernen in moderne multicore-processors mogelijk.

En de Intel-chips van vandaag kunnen, als we het heel simpel mogen houden, over het algemeen worden geconfigureerd om op twee verschillende manieren te werken, bekend als xAPIC-modus en x2APIC-modus.

Hier xAPIC is de "legacy" manier om gegevens uit de interruptcontroller te extraheren, en x2APIC is de modernere manier.

Nog verder vereenvoudigend, vertrouwt xAPIC op wat wordt genoemd MMIO, kort voor geheugen toegewezen invoer/uitvoer, voor het uitlezen van gegevens uit de APIC wanneer deze een interessante gebeurtenis registreert.

In de MMIO-modus kunt u achterhalen wat een APIC-gebeurtenis heeft veroorzaakt door te lezen uit een specifiek geheugengebied (RAM), dat de invoer-/uitvoerregisters van de APIC-chip zelf weerspiegelt.

Deze xAPIC-gegevens worden toegewezen aan een geheugenblok van 4096 bytes ergens in het fysieke RAM-geheugen van de computer.

Dit vereenvoudigt de toegang tot de gegevens, maar het vereist een vervelende, complexe (en, zoals we zullen zien, potentieel gevaarlijke) interactie tussen de APIC-chip en het systeemgeheugen.

x2APIC daarentegen vereist dat u: de APIC-gegevens direct uitlezen van de chip zelf, met behulp van wat bekend staat als Modelspecifieke registers (MSR's).

Volgens Intel, het vermijden van het MMIO-gedeelte van het proces "biedt een aanzienlijk verbeterde adresseerbaarheid van de processor en enkele verbeteringen op de levering van onderbrekingen."

Met name door de APIC-gegevens rechtstreeks uit on-chip registers te extraheren, betekent dit dat de totale hoeveelheid ondersteunde gegevens en het maximale aantal CPU-cores dat tegelijkertijd kan worden beheerd, niet beperkt is tot de 4096 bytes die beschikbaar zijn in de MMIO-modus.

Hoe kun je data hebben waar zelfs de kernel niet naar kan kijken?

Je hebt waarschijnlijk al geraden dat de gegevens die in het MMIO-geheugengebied terechtkomen wanneer je de xAPIC-modus gebruikt, niet altijd zo zorgvuldig worden beheerd als zou moeten...

...en dus dat een soort "datalek" in dat MMIO-gebied de kern van dit probleem is.

Maar gezien het feit dat je heb al bevoegdheden op sysadmin-niveau nodig om de MMIO-gegevens in de eerste plaats te lezen, en daarom zou je toch vrijwel zeker alle gegevens in het geheugen kunnen krijgen ...

...waarom zouden de gegevens van andere mensen per ongeluk in het APIC MMIO-gegevensgebied verschijnen? epic lek?

Het zou in de praktijk sommige soorten data-stelen of RAM-scraping-aanvallen iets gemakkelijker kunnen maken, maar het zou je zeker niet meer geheugen-snooping-vermogen geven dat je in theorie al had?

Helaas is die veronderstelling niet waar als software op het systeem Intel's SGX gebruikt, een afkorting van: Software Guard-uitbreidingen.

---

LEES MEER OVER SGX

---

SGX wordt ondersteund door veel recente Intel-CPU's en biedt de kernel van het besturingssysteem een ​​manier om een ​​stuk code en gegevens in een fysiek RAM-blok te "verzegelen" om zo een zogenaamde enclave te vormen.

Hierdoor gedraagt ​​het zich, althans tijdelijk, net als de speciale beveiligingschips in mobiele telefoons die worden gebruikt om geheimen op te slaan, zoals decoderingssleutels.

Als het SGX-slot van de enclave eenmaal is ingesteld, kan alleen programmacode die in het afgesloten geheugengebied draait de inhoud van dat RAM lezen en schrijven.

Als gevolg hiervan zijn de interne details van alle berekeningen die plaatsvinden nadat de enclave is geactiveerd, onzichtbaar voor andere codes, threads, processen of gebruikers op het systeem.

Inclusief de kernel zelf.

Er is een manier om de code op te roepen die in de enclave is verzegeld, en een manier om de uitvoer van de berekeningen die het zou kunnen uitvoeren te retourneren, maar er is geen manier om de code te herstellen, te bespioneren of te debuggen en de bijbehorende gegevens terwijl het wordt uitgevoerd.

De enclave verandert in feite in een zwarte doos waaraan u invoer kunt toevoegen, zoals gegevens die moeten worden ondertekend met een privésleutel, en uitvoer kunt extraheren, zoals de gegenereerde digitale handtekening, maar waaruit u de cryptografische sleutels niet kunt halen gebruikt in het ondertekeningsproces.

Zoals je je kunt voorstellen, als gegevens die zouden moeten worden verzegeld in een SGX-enclave, ooit per ongeluk zouden worden gedupliceerd in het MMIO RAM dat wordt gebruikt om de APIC-gegevens te "spiegelen" wanneer je de xAPIC "memory-mapped" -modus gebruikt ...

… dat zou de beveiliging van SGX schenden, die zegt dat er nooit gegevens uit een SGX-enclave mogen komen nadat deze is gemaakt, tenzij deze opzettelijk wordt geëxporteerd door code die al in de enclave zelf draait.

Wat veroorzaakt deze epische mislukking in APIC?

De onderzoekers achter de (PIC Lek papier) ontdekte dat door APIC-gegevens uit te lezen via een sluwe en ongebruikelijke reeks geheugentoegangen ...

... ze zouden de processor kunnen misleiden om de APIC MMIO-ruimte niet alleen te vullen met gegevens die vers van de APIC zelf zijn ontvangen, maar ook met gegevens die onlangs door de CPU voor een ander doel zijn gebruikt.

Dit gedrag is een neveneffect van het feit dat hoewel de APIC MMIO-geheugenpagina 4096 bytes groot is, de APIC-chip in xAPIC-modus niet echt 4096 bytes aan gegevens produceert, en de CPU niet altijd correct neutraliseert de ongebruikte delen van het MMIO-gebied door het eerst met nullen te vullen.

In plaats daarvan werden oude gegevens die in de CPU-cache waren overgebleven, weggeschreven samen met de nieuwe gegevens die van de APIC-chip zelf werden ontvangen.

Zoals de onderzoekers het uitdrukken, komt de bug neer op wat bekend staat als an niet-geïnitialiseerd geheugen lezen, waarbij u per ongeluk de overgebleven gegevens van iemand anders in het RAM-geheugen opnieuw gebruikt, omdat noch zij, noch u deze eerst van de eerdere geheimen hebben gewist.

Heeft het ÆPIC-lek gevolgen voor mij?

Voor een volledige lijst van getroffen chips, zie Intel's eigen advies.

Voor zover we kunnen nagaan, heb je waarschijnlijk last van een 10e of 11e generatie Intel-processor.

Maar als je een gloednieuwe CPU van de 12e generatie hebt (de allernieuwste op het moment van schrijven), dan lijkt het erop dat alleen chips van serverklasse worden beïnvloed.

Ironisch genoeg heeft Intel in de 12e-generatie laptopchips SGX opgegeven, dus deze bug is niet van toepassing omdat het onmogelijk is om "verzegelde" SGX-enclaves te hebben die zouden kunnen lekken.

Natuurlijk, zelfs op een potentieel kwetsbare chip, als je niet vertrouwt op software die SGX gebruikt, is de bug ook niet van toepassing.

En de bug, genaamd CVE-2022-21233, kan alleen worden misbruikt door een aanvaller die al lokale beheerderstoegang (root) tot uw computer heeft.

Regelmatige gebruikers heeft geen toegang tot het APIC MMIO-gegevensblok en kan daarom op geen enkele manier naar iets daarin kijken, laat staan ​​naar geheime gegevens die mogelijk uit een SGX-enclave zijn gelekt.

Dus, virtuele gastmachines (VM's) die onder de controle van een hostbesturingssysteem in een hypervisor zoals HyperV, VMWare of VirtualBox draaien, kunnen deze truc vrijwel zeker niet gebruiken om geheimen van andere gasten of de host zelf te plunderen.

Dat komt omdat gast-VM's over het algemeen geen toegang krijgen tot het echte APIC-circuit in de hostprocessor; in plaats daarvan krijgt elke gast zijn eigen gesimuleerde APIC die uniek is voor die VM.

Wat te doen?

Raak niet in paniek.

Op een laptop of desktopcomputer loopt u misschien helemaal geen risico, hetzij omdat u een oudere (of, gelukkig, een gloednieuwe!) computer heeft, of omdat u toch niet op SGX vertrouwt.

En zelfs als je risico loopt, heeft iedereen die als beheerder/root in je laptop komt waarschijnlijk genoeg kracht om je al een wereld van problemen te bezorgen.

Als je kwetsbare servers hebt en je vertrouwt op SGX als onderdeel van je operationele beveiliging, raadpleeg dan Intel-beveiligingsadvies INTEL-SA-00657 voor informatie over bescherming en mitigatie.

Volgens de onderzoekers die dit schreven, "Intel [heeft] microcode- en SGX Software Development Kit-updates uitgebracht om het probleem op te lossen."

Het Linux-kernelteam lijkt nu ook aan een patch te werken waarmee je je systeem zo kunt configureren dat het altijd x2APIC zal gebruiken (die, zoals je je eerder herinnert, geen APIC-gegevens via gedeeld geheugen verzendt), en zal gracieus voorkomen dat het systeem na het opstarten terug naar de xAPIC-modus wordt gedwongen.

---