msm8916-mainline/cve-2022-22063Problema di sicurezza nel firmware dell'hypervisor di alcuni chipset Qualcomm meno recenti.
CVE-2022-22063 è un problema di sicurezza nel firmware dell'hypervisor di alcuni chipset Qualcomm meno recenti. Un componente hardware non protetto (il "boot remapper") può essere abusato per ottenere accesso completo in lettura/scrittura all'hypervisor da un sistema operativo modificato (privilege escalation). Sfruttare il problema è banale sulle piattaforme interessate, poiché non è richiesta la conoscenza della specifica versione del firmware (ad es. indirizzi o variabili).
Nota: Sebbene Qualcomm abbia fornito correzioni ai clienti (con molto tempo a disposizione per rilasciare aggiornamenti), molti dispositivi interessati sono già piuttosto vecchi e potrebbero non ricevere la correzione dal produttore. Il problema può essere sfruttato solo da un sistema operativo modificato o compromesso (utilizzando un altro problema di sicurezza). Mantenere il sistema operativo aggiornato e sicuro potrebbe essere sufficiente anche se il firmware è vulnerabile.
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HIl problema è stato pubblicato anche nel [Bollettino sulla sicurezza di Qualcomm di dicembre 2022].
Il problema dipende da una combinazione di hardware e software in esecuzione sul target interessato:
hyp della memoria interna).APCS_BOOT_START_ADDR_NSEC), che non è protetta dall'hypervisor ed è quindi accessibile dal kernel del sistema operativo meno privilegiato (ad es. Linux).Ci sono molti altri chipset che probabilmente hanno l'hardware interessato (ad es. MSM8909 e MSM8953), ma non dispongono di un firmware hypervisor separato che possa essere compromesso.
Privilege Escalation: Dato un kernel del sistema operativo già compromesso (ad es. Linux), il problema consente di elevare banalmente i privilegi al livello dell'hypervisor (EL1 -> EL2 su ARM). Tutta la memoria gestita dall'hypervisor può essere letta o scritta. Questo rompe l'isolamento dei diversi domini di sicurezza o delle macchine virtuali gestite dall'hypervisor (se presenti, a seconda della configurazione).
(Vedi anche: Un'introduzione al controllo degli accessi sulle piattaforme Qualcomm Snapdragon)
Secure Boot: La maggior parte dei dispositivi Qualcomm disponibili in produzione utilizza il secure boot per impedire modifiche non autorizzate del firmware. Il firmware è firmato crittograficamente e verificato dalla catena di boot. Il problema consente di modificare o addirittura sostituire completamente il firmware dell'hypervisor caricato, in fase di esecuzione, da un sistema operativo modificato (sia tramite lo "sblocco del bootloader" ufficialmente supportato, sia tramite un altro exploit).
(Vedi anche: [Panoramica tecnica su Secure Boot e autenticazione delle immagini Qualcomm (v1.0)] e (v2.0))
Nota: Il problema è stato originariamente trovato sulla piattaforma Qualcomm Snapdragon 410 (MSM8916). Alcune delle spiegazioni seguenti potrebbero essere specifiche di MSM8916, ad es.:
Tuttavia, il concetto generale si applica in modo simile a tutte le piattaforme interessate.
L'architettura ARMv8-A a 64 bit definisce 4 livelli di privilegio ("exception levels", EL). Esistono livelli separati che vengono tipicamente utilizzati per le applicazioni, i kernel dei sistemi operativi e un hypervisor:
La CPU passa da un livello all'altro durante le eccezioni, ad esempio a causa di un interrupt in arrivo. È anche possibile passare da alcuni livelli usando istruzioni speciali, come la Hypervisor Call (hvc).
(Vedi anche: [Modello delle eccezioni AArch64])
L'hypervisor può ospitare una o più macchine virtuali con kernel di sistemi operativi separati. A ogni macchina virtuale può essere fornita una propria visione della memoria utilizzando la traduzione di stage 2. Tutti gli accessi alla memoria da una macchina virtuale passano attraverso due fasi di traduzione: la prima è gestita dal sistema operativo (virtuale), mentre la seconda è gestita dall'hypervisor. La memoria utilizzata dall'hypervisor o da altre macchine virtuali può essere nascosta omettendola dalle tabelle di traduzione.
(Vedi anche: Virtualizzazione AArch64, Gestione della memoria AArch64)
Il firmware dell'hypervisor di Qualcomm viene eseguito in EL2 e utilizza la traduzione di stage 2 per impedire l'accesso alla memoria dell'hypervisor dal kernel del sistema operativo principale in esecuzione in EL1 (di solito Linux). Si noti che in questa configurazione la traduzione di stage 2 è utilizzata principalmente per la protezione della memoria, senza traduzione degli indirizzi. Il sistema operativo principale ha accesso diretto alla maggior parte dei componenti hardware nello spazio di input/output mappato in memoria (MMIO), ad es. il controller SD o il sottosistema della fotocamera. L'accesso alla memoria che appartiene all'hypervisor/EL2 (hyp) e al secure monitor/EL3 (parte di tz) è limitato:
Il boot remapper non è correlato alla virtualizzazione: è necessario durante l'avvio iniziale di un core della CPU. Su questa piattaforma hardware i core della CPU iniziano sempre l'esecuzione all'indirizzo 0x0. Il boot remapper è un componente hardware aggiuntivo costruito attorno alla CPU che rimappa i primi 64 o 128 KiB (0x00000 - 0x20000) in una regione di memoria configurabile.
Per impostazione predefinita il boot remapper punta alla boot ROM (il primo codice che viene eseguito quando il dispositivo viene avviato). Successivamente la mappatura viene modificata in modo che gli altri core della CPU inizino immediatamente l'esecuzione nel firmware EL3 (parte di tz) caricato nella RAM:
Si noti come l'indirizzo a cui accede la CPU (all'interno di tz) sia accessibile utilizzando due diversi indirizzi fisici: l'indirizzo reale nella RAM (0x8650xxxx) e l'indirizzo rimappato tramite il boot remapper (0x0000xxxx).
Esistono in realtà due istanze separate del boot remapper:
APCS_BOOT_START_ADDR_SEC (= 0x0b010004) ma solo in stato sicuro.APCS_BOOT_START_ADDR_NSEC (= 0x0b010008), anche in stato non sicuro.Entrambe le istanze del boot remapper possono essere configurate tramite un registro di memoria che contiene l'indirizzo di base per la regione rimappata e due bit di configurazione: REMAP_EN per abilitare il re-mapping e BOOT_128KB_EN per rimappare i primi 128 KiB invece di soli 64 KiB.
(Vedi anche: Manuale di riferimento tecnico Qualcomm Snapdragon 410E rev. D, pagine 85 e 116)
Usando le conoscenze delle due sezioni precedenti l'idea di base è semplice: Usare il boot remapper per bypassare la protezione della memoria (traduzione di stage 2) dell'hypervisor.
Il boot remapper non funziona solo durante l'avvio della CPU. Può essere usato in qualsiasi momento e consente accesso completo in lettura/scrittura/esecuzione alla regione rimappata. Inoltre, l'hypervisor di Qualcomm non sembra impedire al sistema operativo di configurare e accedere all'istanza non sicura del boot remapper sui dispositivi interessati (non è protetta tramite la traduzione di stage 2). Pertanto, il problema è facile da sfruttare:
hyp che inizia all'indirizzo 0x8640xxxx), seguito da
La regione rimappata può essere spostata dinamicamente (blocco per blocco) per accedere a regioni di memoria più grandi dei 64/128 KiB disponibili tramite il boot remapper. È anche possibile usare questo per disabilitare completamente la protezione della memoria dell'hypervisor (vedi Proof of Concept).
Nota: Lo stesso exploit non funziona per il firmware del mondo sicuro (tz). Sebbene il boot remapper consenta di bypassare la traduzione di stage 2, la regione di memoria tz nella DRAM sembra essere protetta da un componente hardware aggiuntivo (esterno alla CPU) che blocca l'accesso dopo che è passato attraverso il boot remapper:
La regione di memoria tz è probabilmente accessibile solo in stato sicuro. L'exploit consente solo di bypassare la protezione della memoria dell'hypervisor; gli altri meccanismi di sicurezza dell'hardware rimangono attivi.
Il boot remapper può essere usato per disabilitare completamente e sostituire il firmware originale dell'hypervisor in fase di esecuzione, senza conoscere la versione del firmware. In particolare, non è necessario usare il reverse engineering per ottenere gli indirizzi di memoria di variabili e funzioni che potrebbero essere modificate. È sufficiente conoscere la regione di memoria approssimativa del firmware dell'hypervisor, ad es. dalla prenotazione di memoria nel codice Linux open-source o leggendo le intestazioni ELF del binario del firmware dell'hypervisor (disponibile nella partizione hyp della memoria interna).
L'idea generale è:
hvc) per passare dal sistema operativo all'hypervisor (da EL1 a EL2).Il codice che implementa tutto ciò non è lungo, ma coinvolge assembly AArch64 di basso livello e un'attenta interazione con le cache della CPU. Tuttavia, la domanda principale rimane aperta: Dove dovrebbe essere scritto esattamente lo shell code, senza rendere il codice specifico per una particolare versione del firmware dell'hypervisor?
Durante una Hypervisor Call (o qualsiasi eccezione in generale) l'esecuzione della CPU è forzata a uno speciale indirizzo di memoria: il vettore di eccezione. I vettori di eccezione fanno parte di una tabella di vettori più grande che contiene il codice che gestisce diversi tipi di eccezioni, provenienti dal livello corrente o da livelli inferiori:
Ogni riquadro rappresenta un vettore di eccezione con spazio per 32 istruzioni assembly. Questo spazio non è sufficiente, quindi di solito contengono istruzioni di salto che portano da qualche altra parte con più spazio per codice aggiuntivo.
Gli offset sono relativi al Vector Base Address Register (VBAR) che definisce l'indirizzo di base della tabella di vettori per ogni livello di eccezione. L'hypervisor scrive l'indirizzo di base nel registro CPU VBAR_EL2.
Una Hypervisor Call è un'eccezione syncrona generata da un livello di eccezione inferiore (dal kernel del sistema operativo in esecuzione in EL1 all'hypervisor in EL2). Se il kernel del sistema operativo è in esecuzione in modalità a 32 bit, la CPU salterà quindi a VBAR_EL2+0x600, oppure a VBAR_EL2+0x400 in modalità a 64 bit. Dopo aver usato il boot remapper per scrivere codice personalizzato a questo indirizzo ed aver effettuato una Hypervisor Call, la CPU inizierebbe a eseguire lo shell code.
Sfortunatamente VBAR_EL2 non è leggibile dal kernel del sistema operativo in esecuzione in EL1. È leggibile solo dall'hypervisor (EL2) stesso o da livelli superiori. Tuttavia, questa conoscenza rende molto più facile indovinare l'indirizzo di ingresso con la forza bruta: L'indirizzo di base della tabella di vettori deve essere allineato a (un multiplo di) la sua dimensione (0x800 = 2 KiB). Ciò significa che ci sono solo 64 possibili posizioni all'interno di una regione di 128 KiB, o 512 all'interno di una regione di 1 MiB:
I riquadri rossi mostrano tutte le possibili posizioni in cui la CPU potrebbe saltare durante la hypervisor call. Scrivere lo shell code in tutte queste posizioni è sufficiente per mantenere l'approccio indipendente da una particolare versione del firmware (che in realtà avrà la tabella di vettori in un particolare indirizzo).
Questo potrebbe essere ulteriormente migliorato: Il boot remapper consente sia l'accesso in lettura che in scrittura, quindi sarebbe possibile aggiungere alcune euristiche basate sul codice/dati esistenti letti dalle posizioni di memoria. Dovrebbe contenere istruzioni AArch64 (A64) valide e probabilmente alcuni byte di riempimento ripetuti come NOP o istruzioni di salto. (Lo spazio per le 32 istruzioni per vettore di eccezione è spesso solo parzialmente utilizzato perché è più facile saltare a una funzione appropriata con più spazio.)
Il codice di proof of concept incluso in questo repository è una modifica del bootloader Little Kernel (LK) open-source di Qualcomm per la piattaforma Snapdragon 410 (MSM8916/APQ8016), originariamente pensato per essere testato con la scheda di sviluppo DragonBoard 410c. Tutto ciò è stato scelto per semplicità; il problema può essere sfruttato anche da altri sistemi operativi (come Linux), altre piattaforme interessate e persino dispositivi con secure boot, purché ci sia un modo per eseguire codice personalizzato all'interno del kernel del sistema operativo.
Il codice implementa l'approccio descritto sopra per disabilitare completamente l'hypervisor in esecuzione e poi lo sostituisce con una versione diversa. Il nuovo "hypervisor" non supporta alcuna macchina virtuale, ma è in grado di fornire la Risposta alla Domanda Fondamentale sulla Vita, l'Universo e Tutto Quanto usando una semplice hypervisor call:``` $ fastboot oem CVE-2022-22063 < waiting for any device > (bootloader) Hypervisor, what is the Answer to The Ultimate Question of (bootloader) Life, the Universe and Everything? (bootloader) Old hypervisor returned answer: -2 (bootloader) Old non-secure boot remapper base address: 0x100000 (bootloader) Setting boot remapper to hypervisor memory (0x86400000) (bootloader) Using boot remapper to copy shell code to hypervisor memory (bootloader) Copying to all possible vector tables (starting at 0x600) (bootloader) Calling shell code to disable running hypervisor (bootloader) Found old EL2 vector base address at 0x86404000 (bootloader) Copying new code directly to hypervisor memory (0x86400000) (bootloader) Hypervisor, what is the Answer to The Ultimate Question of (bootloader) Life, the Universe and Everything? (bootloader) New hypervisor returned answer: 42 OKAY [ 0.015s] Finished. Total time: 0.015s
### Test
Il codice del proof of concept può essere compilato e testato come segue:```shell
$ git clone https://git.codelinaro.org/clo/la/kernel/lk.git -b caf_migration/LA.BR.1.2.9.1_rb1.5
$ cp CVE-2022-22063.c lk/platform/msm8916/
$ git apply LK.diff
# Build LK for msm8916 and flash it to device
$ fastboot oem CVE-2022-22063
...
Tuttavia, questa configurazione è adatta solo per la scheda di sviluppo DragonBoard 410c e ad altri dispositivi senza secure boot in cui il bootloader primario può essere facilmente (e in sicurezza) sostituito. Il codice in questo repository è fornito principalmente come riferimento e non per un facile utilizzo/test.
In futuro si prevede di integrare il codice in una nuova versione di lk2nd, che può essere testata molto più facilmente su vari dispositivi senza sostituire il bootloader primario.
Secondo Qualcomm, il problema è stato risolto impedendo l'accesso alla regione del boot remapper tramite la traduzione di stadio 2. La configurazione del boot remapper (registro APCS_BOOT_START_ADDR_NSEC) è ancora accessibile, ma ora entrambe le regioni di memoria sono bloccate:
Un'altra possibile correzione sarebbe proteggere il registro APCS_BOOT_START_ADDR_NSEC nell'hypervisor. In questo caso, la regione rimappata potrebbe rimanere accessibile, poiché il sistema operativo non avrebbe alcun modo di riconfigurare il boot remapper su altre regioni di memoria.
Secondo Qualcomm, il problema è stato particolarmente difficile da gestire perché i loro soliti strumenti di automazione non potevano essere utilizzati. La maggior parte dei problemi che ricevono sono problemi software, in cui i dispositivi interessati possono essere identificati controllando il codice sorgente. Per questo problema è stato necessario verificare manualmente sia l'hardware che il software (se la piattaforma ha il registro problematico e se l'hypervisor è vulnerabile). Purtroppo, il mancato utilizzo dell'automazione ha anche comportato che il problema non fosse incluso automaticamente in un bollettino di sicurezza. La seconda estensione dell'embargo è stata richiesta per rendere i clienti consapevoli del problema di sicurezza e dare loro il tempo di applicare le patch ai propri dispositivi. Stanno lavorando per migliorare il processo al fine di evitare tali problemi nelle segnalazioni future.
CVE-2022-22063 Report e diagrammi © 2022 di Stephan Gerhold sono concessi in licenza Creative Commons Attribuzione-Condividi allo stesso modo 4.0 Internazionale (CC BY-SA 4.0). 
Il codice proof of concept (CVE-2022-22063.c) è fornito sotto la licenza MIT.