APIC/EPIC! I chip Intel trapelano segreti che anche il kernel non dovrebbe vedere...

Ecco il BWAIN di questa settimana, il nostro termine scherzoso per a Bug con un nome impressionante.

BWAIN è un riconoscimento che diamo quando un nuovo difetto di sicurezza informatica non solo si rivela interessante e importante, ma si presenta anche con il proprio logo, nome di dominio e sito web.

Questo è doppiato Perdita ÆPIC, un gioco di parole APIC ed EPIC.

Il primo è l'abbreviazione di Controller di interrupt programmabile avanzato, e quest'ultima è semplicemente la parola "epica", come in gigante, massiccio, estremo, mega, gigantesco.

La lettera Æ non è stata usata nell'inglese scritto dai tempi dei sassoni. Il suo nome è esc, pronunciato cenere (come nell'albero), e rappresenta più o meno il suono del La nella parola moderna ASH. Ma supponiamo che tu debba pronunciare la parola EPIC qui sia come "APIC-slash-EPIC", o come "ah!-eh?-PIC".

Di cosa si tratta?

Tutto ciò solleva cinque affascinanti domande:

• Che cos'è un APIC, e perché ne ho bisogno?
• Come puoi avere dati che anche il nocciolo non puoi sbirciare?
• Cosa causa questo fallimento epico nell'APIC?
• Se la Perdita ÆPIC influenzami?
• Cosa fare a proposito?

Cos'è un APIC?

Torniamo al 1981, quando apparve per la prima volta il PC IBM.

Il PC includeva un chip chiamato il Controller di interrupt programmabile Intel 8259A, o PIC. (I modelli successivi, dal PC AT in poi, avevano due PIC, concatenati insieme, per supportare più eventi di interruzione.)

Lo scopo del PIC era letteralmente quello di interrompere il programma in esecuzione sul processore centrale (CPU) del PC ogni volta che si verificava qualcosa di critico che richiedeva attenzione immediatamente.

Questi interrupt hardware includevano eventi come: la tastiera che riceveva una sequenza di tasti; la porta seriale che riceve un carattere; e un timer hardware ripetuto che scorre.

Senza un sistema di interruzione hardware di questo tipo, il sistema operativo dovrebbe essere disseminato di chiamate di funzione per controllare regolarmente la pressione dei tasti in entrata, il che sarebbe uno spreco di potenza della CPU quando nessuno digita, ma non risponderebbe abbastanza quando l'hanno fatto.

Come puoi immaginare, il PIC è stato presto seguito da un chip aggiornato chiamato il APIC, una Avanzate sorta di PIC integrato nella CPU stessa.

Al giorno d'oggi, gli APIC forniscono molto di più del semplice feedback dalla tastiera, dalla porta seriale e dal timer di sistema.

Gli eventi APIC vengono attivati ​​(e forniscono dati in tempo reale su) eventi come il surriscaldamento e consentono l'interazione hardware tra i diversi core nei processori multicore contemporanei.

E i chip Intel di oggi, se possiamo semplificare notevolmente, possono generalmente essere configurati per funzionare in due modi diversi, noti come xModalità APIC ed x2Modalità APIC.

Qui, xAPIC è il modo "legacy" di estrarre i dati dal controller di interrupt, e x2APIC è il modo più moderno.

Semplificando ulteriormente, xAPIC si basa su ciò che viene chiamato MMIO, abbreviazione di input/output mappato in memoria, per leggere i dati dell'APIC quando registra un evento di interesse.

In modalità MMIO, puoi scoprire cosa ha attivato un evento APIC leggendo da una specifica regione di memoria (RAM), che rispecchia i registri di input/output del chip APIC stesso.

Questi dati xAPIC sono mappati in un blocco di memoria da 4096 byte da qualche parte nella RAM fisica del computer.

Ciò semplifica l'accesso ai dati, ma richiede un'interazione fastidiosa, complessa (e, come vedremo, potenzialmente pericolosa) tra il chip APIC e la memoria di sistema.

Al contrario, x2APIC richiede di farlo leggere direttamente i dati APIC dal chip stesso, utilizzando i cosiddetti Registri specifici del modello (MSR).

Secondo Intel, evitare la parte MMIO del processo "fornisce un'indirizzabilità del processore significativamente maggiore e alcuni miglioramenti nella consegna degli interrupt".

In particolare, estrarre i dati APIC direttamente dai registri su chip significa che la quantità totale di dati supportati e il numero massimo di core CPU che possono essere gestiti contemporaneamente, non è limitato ai 4096 byte disponibili in modalità MMIO.

Come puoi avere dati che nemmeno il kernel può sbirciare?

Probabilmente hai già intuito che i dati che finiscono nell'area di memoria MMIO quando si utilizza la modalità xAPIC non sono sempre gestiti con la stessa attenzione come dovrebbe essere...

... e quindi che una sorta di "fuga di dati" in quell'area MMIO è il cuore di questo problema.

Ma dato che tu necessitano già di poteri a livello di amministratore di sistema per leggere i dati MMIO in primo luogo, e quindi quasi sicuramente potresti comunque ottenere qualsiasi dato in memoria ...

...perché la visualizzazione dei dati di altre persone per errore nell'area dati APIC MMIO rappresenta un epica perdita?

In pratica potrebbe rendere leggermente più semplici alcuni tipi di attacchi di furto di dati o di scraping della RAM, ma sicuramente non ti darebbe più capacità di snooping della memoria che avevi già in teoria?

Sfortunatamente, tale presupposto non è vero se qualsiasi software sul sistema utilizza SGX di Intel, abbreviazione di Estensioni di protezione del software.

---

SCOPRI DI PIÙ SU SGX

---

SGX è supportato da molte recenti CPU Intel e fornisce un modo per il kernel del sistema operativo di "sigillare" un blocco di codice e dati in un blocco fisico di RAM in modo da formare ciò che è noto come un'enclave.

Questo lo fa comportare, almeno temporaneamente, in modo molto simile agli speciali chip di sicurezza nei telefoni cellulari utilizzati per memorizzare segreti come le chiavi di decrittazione.

Una volta impostato il "blocco" SGX dell'enclave, solo il codice del programma in esecuzione all'interno dell'area di memoria sigillata può leggere e scrivere il contenuto di quella RAM.

Di conseguenza, i dettagli interni di tutti i calcoli che si verificano dopo l'attivazione dell'enclave sono invisibili a qualsiasi altro codice, thread, processo o utente nel sistema.

Compreso il kernel stesso.

C'è un modo per chiamare il codice che è stato sigillato nell'enclave e un modo per restituire l'output dei calcoli che potrebbe eseguire, ma non c'è modo di recuperare, spiare o eseguire il debug del codice e i dati associati durante l'esecuzione.

L'enclave si trasforma di fatto in una scatola nera a cui alimentare input, come un dato da firmare con una chiave privata, ed estrarre output, come la firma digitale generata, ma da cui non si possono smascherare le chiavi crittografiche utilizzato nel processo di firma.

Come puoi immaginare, se i dati che dovrebbero essere sigillati all'interno di un'enclave SGX dovessero mai essere duplicati accidentalmente nella RAM MMIO utilizzata per "rispecchiare" i dati APIC quando si utilizza la modalità xAPIC "mappata in memoria" ...

...questo violerebbe la sicurezza di SGX, che dice che nessun dato dovrebbe mai emergere da un'enclave SGX dopo che è stata creata, a meno che non sia deliberatamente esportato dal codice già in esecuzione all'interno dell'enclave stessa.

Cosa causa questo fallimento epico in APIC?

I ricercatori dietro il ÆPIC Perdita di carta scoprì che provvedendo a leggere i dati APIC tramite un'astuta e insolita sequenza di accessi alla memoria...

... potrebbero indurre il processore a riempire lo spazio MMIO APIC non solo con i dati appena ricevuti dall'APIC stesso, ma anche con i dati che sono stati utilizzati di recente dalla CPU per qualche altro scopo.

Questo comportamento è un effetto collaterale del fatto che sebbene la pagina di memoria APIC MMIO abbia una dimensione di 4096 byte, il chip APIC in modalità xAPIC non produce effettivamente 4096 byte di dati e la CPU non neutralizza sempre correttamente le parti inutilizzate della regione MMIO riempiendola prima con zeri.

Invece, i vecchi dati rimasti nella cache della CPU sono stati scritti insieme ai nuovi dati ricevuti dal chip APIC stesso.

Come dicono i ricercatori, il bug si riduce a ciò che è noto come an lettura della memoria non inizializzata, in cui riutilizzi accidentalmente i dati rimanenti di qualcun altro nella RAM perché né loro né tu lo hai prima cancellato dai suoi segreti precedenti.

La perdita ÆPIC mi riguarda?

Per un elenco completo dei chip interessati, vedere La consulenza di Intel.

Per quanto ne sappiamo, se hai un processore Intel di decima o undicesima generazione, probabilmente sei interessato.

Ma se hai una CPU di 12a generazione nuova di zecca (l'ultima al momento della scrittura), sembra che solo i chip di classe server siano interessati.

Ironia della sorte, nei chip per laptop di 12a generazione, Intel ha rinunciato a SGX, quindi questo bug non si applica perché è impossibile avere enclavi SGX "sigillate" che potrebbero perdere.

Ovviamente, anche su un chip potenzialmente vulnerabile, se non fai affidamento su alcun software che utilizza SGX, il bug non si applica nemmeno.

E il bug, doppiato CVE-2022-21233, può essere sfruttato solo da un utente malintenzionato che ha già accesso locale a livello di amministratore (root) al tuo computer.

Utenti abituali non può accedere al blocco di dati APIC MMIO e quindi non ha modo di sbirciare lì dentro, per non parlare dei dati segreti che potrebbero essere trapelati da un'enclave SGX.

Inoltre macchine virtuali ospiti (VM) in esecuzione sotto il controllo di un sistema operativo host in un hypervisor come HyperV, VMWare o VirtualBox quasi certamente non possono utilizzare questo trucco per depredare segreti da altri ospiti o dall'host stesso.

Questo perché le VM guest generalmente non ottengono l'accesso al vero circuito APIC nel processore host; invece, ogni guest ottiene il proprio APIC simulato che è unico per quella macchina virtuale.

Cosa fare?

Non fatevi prendere dal panico.

Su un laptop o un computer desktop, potresti non essere affatto a rischio, o perché hai un computer più vecchio (o, fortunatamente, un nuovo di zecca!), o perché comunque non ti affidi a SGX.

E anche se sei un rischio, chiunque entri nel tuo laptop come amministratore/root probabilmente ha abbastanza potenza per causarti già un mondo di problemi.

Se disponi di server vulnerabili e ti affidi a SGX come parte della tua sicurezza operativa, controlla l'avviso di sicurezza di Intel INTEL-SA-00657 per informazioni sulla protezione e la mitigazione.

Secondo i ricercatori che lo hanno scritto, "Intel [ha] rilasciato gli aggiornamenti del microcodice e del kit di sviluppo software SGX per risolvere il problema".

Il team del kernel di Linux sembra anche lavorare in questo momento su una patch che ti consentirà di configurare il tuo sistema in modo che utilizzi sempre x2APIC (che, come ricorderai in precedenza, non trasmette dati APIC tramite memoria condivisa), e impedirà con grazia che il sistema venga forzato di nuovo in modalità xAPIC dopo l'avvio.

---