Perché utilizzare MTE?
I bug di sicurezza della memoria, ovvero errori nella gestione della memoria nei linguaggi di programmazione nativi, sono problemi comuni relativi al codice. Portano a vulnerabilità di sicurezza e problemi di stabilità.
Armv9 ha introdotto l'ARM Memory Tagging Extension (MTE), un'estensione hardware che consente di individuare i bug use-after-free e di buffer-overflow nel codice nativo.
Verificare la presenza di assistenza
A partire da Android 13, alcuni dispositivi supportano la funzionalità MTE. Per verificare se sul dispositivo è in esecuzione la funzionalità MTE, esegui questo comando:
adb shell grep mte /proc/cpuinfo
Se il risultato è Features : [...] mte
, significa che sul dispositivo è attiva la funzionalità MTE.
Alcuni dispositivi non attivano la funzionalità MTE per impostazione predefinita, ma consentono agli sviluppatori di riavviarsi con la funzionalità MTE abilitata. Questa è una configurazione sperimentale non consigliata per il normale utilizzo in quanto potrebbe ridurre le prestazioni o la stabilità del dispositivo, ma può essere utile per lo sviluppo di app. Per accedere a questa modalità, vai a Opzioni sviluppatore > Estensione per il tagging della memoria nell'app Impostazioni. Se questa opzione non è presente, il dispositivo non supporta l'attivazione della funzionalità MTE in questo modo.
Modalità operative MTE
MTE supporta due modalità: SYNC e ASYNC. La modalità SYNC fornisce migliori informazioni diagnostiche ed è quindi più adatta per scopi di sviluppo, mentre la modalità ASYNC ha prestazioni elevate che ne consentono l'abilitazione per le app rilasciate.
Modalità sincrona (SYNC)
Questa modalità è ottimizzata per il debug rispetto alle prestazioni e può essere utilizzata come strumento preciso per il rilevamento di bug, quando è accettabile un overhead di prestazioni più elevato. Quando questa opzione è abilitata, MTE SYNC agisce anche come mitigazione della sicurezza.
In caso di mancata corrispondenza tra i tag, il processore termina il processo in caso di caricamento o istruzione di archivio in violazione con SIGSEGV (con si_code SEGV_MTESERR) e informazioni complete sull'accesso alla memoria e sull'indirizzo in cui è stato riscontrato l'errore.
Questa modalità è utile durante i test come alternativa più veloce a HWASan che non richiede la ricompilazione del codice, oppure in produzione, quando l'app rappresenta una superficie di attacco vulnerabile. Inoltre, quando la modalità ASYNC (descritta di seguito) rileva un bug, è possibile ottenere una segnalazione di bug accurata utilizzando le API di runtime per impostare l'esecuzione in modalità SYNC.
Inoltre, durante l'esecuzione in modalità SYNC, l'allocatore di Android registra l'analisi dello stack di ogni allocazione e deallocation e li utilizza per fornire report sugli errori migliori che includono la spiegazione di un errore di memoria, come use-after-free o buffer-overflow, e le analisi dello stack degli eventi di memoria pertinenti (per maggiori dettagli, consulta Informazioni sui report MTE). Questi report forniscono più informazioni contestuali e semplificano l'individuazione e la correzione dei bug rispetto alla modalità ASYNC.
Modalità asincrona (ASYNC)
Questa modalità è ottimizzata per le prestazioni rispetto all'accuratezza delle segnalazioni di bug e può essere utilizzata per il rilevamento di overhead ridotto dei bug di sicurezza della memoria. In caso di mancata corrispondenza tra i tag, il processore continua l'esecuzione fino alla voce del kernel più vicina (ad esempio, chiamata di sistema o interruzione del timer), dove termina il processo con SIGSEGV (codice SEGV_MTEAERR) senza registrare l'indirizzo in cui è stato riscontrato l'errore o l'accesso alla memoria.
Questa modalità è utile per mitigare le vulnerabilità di sicurezza della memoria in produzione su codebase ben testati in cui è noto che la densità dei bug di sicurezza della memoria sia bassa, un risultato ottenuto utilizzando la modalità SYNC durante i test.
Attiva MTE
Per un singolo dispositivo
Ai fini della sperimentazione, è possibile utilizzare le modifiche alla compatibilità delle app per impostare il valore predefinito dell'attributo memtagMode
per un'applicazione che non specifica alcun valore nel file manifest (o non specifica "default"
).
Puoi trovarle in Sistema > Avanzate > Opzioni sviluppatore > Modifiche compatibilità app nel menu delle impostazioni globali. L'impostazione di NATIVE_MEMTAG_ASYNC
o NATIVE_MEMTAG_SYNC
consente di attivare la funzionalità MTE per una determinata applicazione.
In alternativa, può essere impostato utilizzando il comando am
come segue:
- Per la modalità SINCRONIZZAZIONE:
$ adb shell am compat enable NATIVE_MEMTAG_SYNC my.app.name
- Per la modalità ASYNC:
$ adb shell am compat enable NATIVE_MEMTAG_ASYNC my.app.name
In Gradle
Puoi attivare MTE per tutte le build di debug del tuo progetto Gradle inserendo
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools">
<application android:memtagMode="sync" tools:replace="android:memtagMode"/>
</manifest>
in app/src/debug/AndroidManifest.xml
. Questa operazione sostituirà l'elemento memtagMode
del manifest con la sincronizzazione per le build di debug.
In alternativa, puoi abilitare MTE per tutte le build di un buildType personalizzato. A questo scopo, crea il tuo buildType e inserisci il codice XML in app/src/<name of buildType>/AndroidManifest.xml
.
Per un APK su qualsiasi dispositivo supportato
La funzionalità MTE è disattivata per impostazione predefinita. Per farlo, le app che vogliono utilizzare la funzionalità MTE possono farlo impostando android:memtagMode
nel tag <application>
o <process>
in AndroidManifest.xml
.
android:memtagMode=(off|default|sync|async)
Se impostato nel tag <application>
, l'attributo influisce su tutti i processi utilizzati
dall'applicazione e può essere sostituito per i singoli processi impostando
il tag <process>
.
Esegui l'app
Dopo aver attivato la funzionalità MTE, utilizza e testa la tua app normalmente. Se viene rilevato un problema di sicurezza della memoria, la tua app si arresta in modo anomalo e mostra una lapide simile a questa (nota l'SIGSEGV
con SEGV_MTESERR
per SYNC o SEGV_MTEAERR
per ASYNC):
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<<
uid: 0
tagged_addr_ctrl: 000000000007fff3
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0
Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0
x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0
x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021
x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030
x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000
x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78
x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000
x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000
x28 0000000000000000 x29 0000007fe8191b70
lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
backtrace:
#00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
#01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
#02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
#03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331)
deallocated by thread 13935:
#00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331)
#01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331)
#02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
#03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
allocated by thread 13935:
#00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331)
#01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331)
#02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331)
#03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
#04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
Learn more about MTE reports: https://source.android.com/docs/security/test/memory-safety/mte-report
Per ulteriori dettagli, consulta Informazioni sui report sugli MTE nella documentazione di AOSP. Puoi anche eseguire il debug dell'app con Android Studio e il debugger si ferma sulla riga causando l'accesso alla memoria non valido.
Utenti avanzati: utilizzare MTE nel proprio allocatore
Per utilizzare MTE per la memoria non allocata tramite i normali allocatori di sistema, devi modificare l'allocatore in modo da assegnare tag alla memoria e ai puntatori.
Le pagine del tuo allocatore devono essere allocate utilizzando PROT_MTE
nel flag prot
di mmap
(o mprotect
).
Tutte le allocazioni con tag devono essere allineate a 16 byte, poiché i tag possono essere assegnati solo per blocchi da 16 byte (noti anche come granuli).
Quindi, prima di restituire un puntatore, devi utilizzare l'istruzione IRG
per generare un tag casuale e memorizzarlo nel puntatore.
Segui queste istruzioni per taggare la memoria sottostante:
STG
: tagga un singolo granulo di 16 byteST2G
: tagga due granuli di 16 byteDC GVA
: riga della cache del tag con lo stesso tag
In alternativa, anche le seguenti istruzioni non inizializzano la memoria:
STZG
: tag e inizializzato zero un singolo granule di 16 byteSTZ2G
: tag e inizializzato zero due granuli da 16 byteDC GZVA
: tag e nessuna inizializzazione della cache con lo stesso tag
Tieni presente che queste istruzioni non sono supportate sulle CPU meno recenti, quindi devi eseguirle in modo condizionale quando è abilitata la funzionalità MTE. Puoi controllare se la funzionalità MTE è abilitata per il tuo processo:
#include <sys/prctl.h>
bool runningWithMte() {
int mode = prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0);
return mode != -1 && mode & PR_MTE_TCF_MASK;
}
Potresti trovare utile l'implementazione scudo come riferimento.
Scopri di più
Puoi trovare ulteriori informazioni nella guida dell'utente di MTE per Android OS redatta da Arm.