APIC/EPIC! Intel-chips läcker hemligheter som inte ens kärnan borde se...

Här är veckans BWAIN, vår skämtsamma term för en Bugg Med Ett Imponerande Namn.

BWAIN är en utmärkelse som vi delar ut när ett nytt cybersäkerhetsfel inte bara visar sig vara intressant och viktigt, utan också dyker upp med sin egen logotyp, domännamn och hemsida.

Den här är dubbad ÆPIC-läcka, en ordlek på orden APIC och EPISK.

Det förra är en förkortning för Avancerad programmerbar avbrottskontroll, och det senare är helt enkelt ordet "episkt", som i jätte, massiv, extrem, Mega, humongous.

Bokstaven Æ har inte använts i skriven engelska sedan saxisk tid. Dess namn är æsc, uttalad aska (som i trädet), och det representerar ganska mycket ljudet av A i det moderna ordet ASH. Men vi antar att du ska uttala ordet ÆPIC här antingen som "APIC-slash-EPIC", eller som "ah!-eh?-PIC".

Vad handlar det om?

Allt detta väcker fem fascinerande frågor:

• Vad är en APIC, och varför behöver jag det?
• Hur kan du ha data som även kärnan kan du inte kika på?
• Vad orsakar detta episka misslyckande i APIC?
• Har ÆPIC-läcka påverka mig?
• Vad ska man göra om det?

Vad är en APIC?

Låt oss spola tillbaka till 1981, när IBM PC:n dök upp för första gången.

Datorn innehöll ett chip som heter Intel 8259A programmerbar avbrottskontroll, eller PIC. (Senare modeller, från PC AT och framåt, hade två PIC:er, sammankopplade för att stödja fler avbrottshändelser.)

Syftet med PIC var bokstavligen att avbryta programmet som körs på PC:ns centrala processor (CPU) när något tidskritiskt inträffade som behövde uppmärksamhet direkt.

Dessa hårdvaruavbrott inkluderade händelser såsom: tangentbordet får en tangenttryckning; serieporten tar emot ett tecken; och en återkommande hårdvarutimer som tickar över.

Utan ett maskinvaruavbrottssystem av det här slaget skulle operativsystemet behöva fyllas med funktionsanrop för att kontrollera om det finns inkommande tangenttryckningar regelbundet, vilket skulle vara ett slöseri med CPU-kraft när ingen skrev, men inte skulle vara lyhörd nog när de gjorde det.

Som du kan föreställa dig följdes PIC snart av ett uppgraderat chip kallat the APIC, En avancerat typ av PIC inbyggd i själva processorn.

Dessa dagar ger APIC mycket mer än bara feedback från tangentbordet, serieporten och systemtimern.

APIC-händelser utlöses av (och tillhandahåller realtidsdata om) händelser som överhettning och tillåter hårdvaruinteraktion mellan de olika kärnorna i moderna flerkärniga processorer.

Och dagens Intel-chips, om vi förenklat, kan i allmänhet konfigureras för att fungera på två olika sätt, kända som xAPIC-läge och x2APIC-läge.

Här, xAPIC är det "legacy" sättet att extrahera data från avbrottskontrollanten, och x2APIC är det mer moderna sättet.

För att förenkla ytterligare, förlitar sig xAPIC på vad som kallas MMIO, Förkortning av minnesmappad ingång/utgång, för att läsa data från APIC när den registrerar en händelse av intresse.

I MMIO-läge kan du ta reda på vad som utlöste en APIC-händelse genom att läsa från en specifik minnesregion (RAM), som speglar in-/utgångsregistren för själva APIC-chippet.

Dessa xAPIC-data mappas till ett 4096-byte minnesblock någonstans i datorns fysiska RAM.

Detta förenklar åtkomsten till data, men det kräver en irriterande, komplex (och, som vi ska se, potentiellt farlig) interaktion mellan APIC-chippet och systemminnet.

Däremot kräver x2APIC att du gör det läsa ut APIC-data direkt från själva chippet, med hjälp av vad som kallas Modellspecifika register (MSR).

Enligt Intel undviker MMIO-delen av processen "ger avsevärt ökad processoradresserbarhet och vissa förbättringar av avbrottsleverans."

Att extrahera APIC-data direkt från on-chip-register innebär att den totala mängden data som stöds, och det maximala antalet CPU-kärnor som kan hanteras samtidigt, inte är begränsade till de 4096 byte som är tillgängliga i MMIO-läge.

Hur kan du ha data som inte ens kärnan kan kika på?

Du har förmodligen redan gissat att data som hamnar i MMIO-minnesområdet när du använder xAPIC-läge inte alltid hanteras så noggrant som det borde vara...

…och därmed att någon form av "dataläcka" in i det MMIO-området är hjärtat av detta problem.

Men med tanke på att du behöver redan befogenheter på sysadminnivå att läsa MMIO-data i första hand, och därför kan du nästan säkert komma åt vilken data som helst i minnet ändå...

…varför skulle andras data dyka upp av misstag i APIC MMIO-dataområdet representera en episk läcka?

Det kanske gör vissa typer av datastöldande eller RAM-skrapsattacker något lättare i praktiken, men det skulle väl inte ge dig någon mer minnessnoopförmåga som du redan hade i teorin?

Tyvärr är det antagandet inte sant om någon programvara på systemet använder Intels SGX, förkortning för Software Guard -tillägg.

---

LÄS MER OM SGX

---

SGX stöds av många nya Intel-processorer, och det ger ett sätt för operativsystemets kärna att "försluta" en bit kod och data i ett fysiskt RAM-block för att bilda vad som kallas en enklav.

Detta gör att den, åtminstone tillfälligt, beter sig ungefär som de speciella säkerhetschips i mobiltelefoner som används för att lagra hemligheter som dekrypteringsnycklar.

När enklavens SGX "lås" är inställt, kan endast programkod som körs i det avstängda minnesområdet läsa och skriva innehållet i det RAM-minnet.

Som ett resultat är de interna detaljerna för alla beräkningar som sker efter att enklaven har aktiverats osynliga för någon annan kod, tråd, process eller användare i systemet.

Inklusive själva kärnan.

Det finns ett sätt att anropa koden som har förseglats in i enklaven, och ett sätt för den att returnera utdata från de beräkningar den kan utföra, men det finns inget sätt att återställa, eller att spionera på, eller att felsöka, koden och tillhörande data medan den körs.

Enklaven förvandlas effektivt till en svart låda till vilken du kan mata indata, såsom en data som ska signeras med en privat nyckel, och extrahera utgångar, såsom den digitala signaturen som genereras, men från vilken du inte kan blinka ut de kryptografiska nycklarna används i signeringsprocessen.

Som du kan föreställa dig, om data som ska vara förseglade inuti en SGX-enklav av misstag skulle dupliceras till MMIO RAM-minnet som används för att "spegla" APIC-data när du använder xAPIC "minne-mappat" läge ...

…det skulle bryta mot säkerheten för SGX, som säger att ingen data någonsin får komma ut från en SGX-enklav efter att den har skapats, såvida den inte medvetet exporteras av kod som redan körs inuti själva enklaven.

Vad orsakar detta episka misslyckande i APIC?

Forskarna bakom ÆPIC Läckagepapper upptäckte att genom att ordna med att läsa ut APIC-data via en listig och ovanlig sekvens av minnesåtkomster...

…de kunde lura processorn att fylla upp APIC MMIO-utrymmet inte bara med data som nyligen tagits emot från själva APIC:n, utan också med data som nyss råkade ha använts av CPU:n för något annat ändamål.

Detta beteende är en bieffekt av det faktum att även om APIC MMIO-minnessidan är 4096 byte stor, så producerar APIC-chippet i xAPIC-läge faktiskt inte 4096 bytes data, och CPU:n neutraliserar inte alltid korrekt. de oanvända delarna av MMIO-regionen genom att först fylla den med nollor.

Istället skrevs gammal data över i CPU-cachen ut tillsammans med den nya data som tagits emot från själva APIC-chippet.

Som forskarna uttryckte det, kokar buggen ner till vad som är känt som en oinitierad minnesläsning, där du av misstag återanvänder någon annans överblivna data i RAM eftersom varken de eller du rensade bort det från dess tidigare hemligheter först.

Påverkar ÆPIC-läckan mig?

För en fullständig lista över påverkade marker, se Intels egen rådgivning.

Så vitt vi kan säga, om du har en 10:e eller 11:e generationens Intel-processor, är du förmodligen påverkad.

Men om du har en helt ny 12:e generationens CPU (den allra senaste i skrivande stund), så verkar det som om endast serverklasschips påverkas.

Ironiskt nog har Intel i 12:e generationens laptopchip gett upp SGX, så det här felet gäller inte eftersom det är omöjligt att ha några "förseglade" SGX-enklaver som kan läcka.

Naturligtvis, även på ett potentiellt sårbart chip, om du inte förlitar dig på någon programvara som använder SGX, så gäller inte buggen heller.

Och buggen, dubbad CVE-2022-21233, kan endast utnyttjas av en angripare som redan har lokal administratörsnivå (root) åtkomst till din dator.

Regelbundna användare kan inte komma åt APIC MMIO-datablocket och har därför inget sätt att kika på någonting alls där inne, än mindre hemlig data som kan ha läckt ut från en SGX-enklav.

Också, virtuella gästmaskiner (VM) som körs under kontroll av ett värdoperativsystem i en hypervisor som HyperV, VMWare eller VirtualBox kan nästan säkert inte använda detta trick för att plundra hemligheter från andra gäster eller värden själv.

Det beror på att virtuella gästdatorer i allmänhet inte får tillgång till den verkliga APIC-kretsen i värdprocessorn; istället får varje gäst sin egen simulerade APIC som är unik för den virtuella datorn.

Vad göra?

Få inte panik.

På en bärbar eller stationär dator kanske du inte är i riskzonen alls, antingen för att du har en äldre (eller som tur är, en helt ny!) dator, eller för att du ändå inte litar på SGX.

Och även om du är riskfylld, har alla som kommer in i din bärbara dator som administratör/root förmodligen tillräckligt med kraft för att orsaka dig en värld av problem redan.

Om du har sårbara servrar och du litar på SGX som en del av din driftsäkerhet, kolla Intels säkerhetsrådgivning INTEL-SA-00657 för skydd och begränsningsinformation.

Enligt forskarna som skrev detta, "Intel [har] släppt uppdateringar av mikrokod och SGX Software Development Kit för att åtgärda problemet."

Linux-kärnteamet verkar också arbeta just nu med en patch som gör att du kan konfigurera ditt system så att det alltid kommer att använda x2APIC (som, som du kommer ihåg från tidigare, inte överför APIC-data via delat minne), och kommer att förhindra att systemet tvingas tillbaka till xAPIC-läge efter uppstart.

---