Con Android 4.4 KitKat, Google ha introdotto una miriade di nuove funzionalità, soprattutto per quanto riguarda la sicurezza del dispositivo. Oltre a SELinux abilitato di default, in Android 4.4 Google ha aggiunto una nuova feature: dm-verity, la quale potrebbe anche compromettere il lavoro dei tanti sviluppatori di Custom ROMs.
Come accennato sopra, Android 4.4 KitKat ha introdotto nuove funzionalità e ottimizzazioni, anche per quanto riguarda la sicurezza del dispositivo. Tra queste spicca dm-verity , una feature del kernel che si occupa di effettuare il check al boot sull’integrità dei blocchi del File System.
(I blocchi non sono altro che una sequenza di Byte o Bit a lunghezza fissa [dimensione del blocco]. Generalmente su dispositivi Flash la dimensione dei blocchi è di 4Kb. Per chiarire il concetto, un file di 1Mb verrà salvato fisicamente sulla memoria Flash in 250 blocchi da 4Kb).
Dm-verity , stando a quanto affermato sul sito ufficiale, serve e servirà per evitare a Rootkits e malware di effettuare modifiche sul File System. In sostanza, ogni volta che viene scritto un dato su disco, l’hash del blocco cambia, e se questo cambiamento non è autorizzato dal sistema, dm-verity al boot successivo rileverà il cambiamento, bloccando l’esecuzione.
il concetto alla base di DM-Verity
Dm-verity risiederà nel kernel. Quindi, se un software comprometterà il filesystem prima dell’avvio del kernel, questo bloccherà l’avvio del dispositivo.
Ad ora, i produttori utilizzano una chiave univoca per ogni dispositivo, scritta in qualche remoto angolo della memoria dello stesso, la quale non può più essere cambiata una volta che il dispositivo ha lasciato la fabbrica di produzione. Con questa chiave i produttori verificano l’integrità del primo livello del bootloader, il quale poi si occuperà della verifica dei livelli superiori.
Al momento però, la verifica viene eseguita solo sui bootloaders, tralasciando la verifica del kernel e successivamente del File System. Qui entra in gioco dm-verity, il quale si occupa della verifica in parallelo dell’hash di ogni blocco quando il sistema vi accede (per evitare eccessivi ritardi durante l’accesso alla memoria) e lo compara con “l’albero di hash” salvato precedentemente (immagine sopra) . se questi divergono, ogni blocco con hash diverso da quello precedentemente generato, verrà reso inaccessibile e di conseguenza verrà restituito un errore I/O, indicante che il blocco non risulta leggibile. In parole povere, il filesystem risulterà corrotto.
come opererà fisicamente dm-verity
- Generazione di un’immagine di sistema in formato EXT4
- Generazione dell’albero di hash
Per generare l’hash “root” l’immagine di sistema verrà divisa in blocchi da 4Kb (layer 0), ad ognuno dei quali verrà assegnato un hash SHA256. Il Layer 1 verrà composto unendo gli SHA256 precedenti e dividendo il risultante in blocchi da 4Kb, generando un’immagine di dimensione minore. Il procedimento verrà ripetuto sino a quando lo SHA256 potrà stare all’interno di un singolo blocco da 4k.
La dimensione dell’albero di hash varierà in base alla dimensione della partizione, ma mediamente al di sotto dei 30Mb. - Costruzione della tabella di mappatura
Questa tabella identifica il blocco(porzione) del file system analizzata durante la generazione dell’hash. Conterrà anche la posizione dell’albero di hash e l’offset/posizione del blocco di partenza . - Firma e convalida della tabella sopra generata
La tabella generata precedentemente verrà “firmata” con una chiave RSA-2048 posta nella partizione /boot. Generalmente queste chiavi sono private e generate in fase di produzione del dispositivo.
Il problema da punto di vista del rooting e del modding
Bene, vi ho scritto il funzionamento di dm-verity, ora è il momento di analizzare la situazione Modding/rooting applicata a questa nuova feature.
Ad eccezione dei dispositivi Nexus, che notoriamente sono sbloccabili con un semplice “fastboot oem unlock”, tutti gli altri dispositivi potrebbero, in futuro, non vedere più il root o custom roms. Perchè dico questo?? semplicemente perchè dm-verity intercetterà qualsiasi modifica eseguita sul file-system e di conseguenza qualsiasi file scritto o modificato senza autorizzazione. Va da se quindi che per dispositivi con bootloader bloccato e sbloccabili solo tramite una chiave univoca, trovare un exploit per avere l’accesso come amministratore risulterà decisamente piu’ difficile. Questo significa che, se il produttore deciderà di non rilasciare nessun tool di sblocco del bootloader, non sarà possibile trovare un modo per sbloccare il bootloader. E’ anche vero che dm-verity potrà essere disabilitato nel kernel o modificato in modo che legga una chiave RSA personale invece di quella dell’OEM, ma per fare tutto ciò è necessario avere un bootloader sbloccato per poter scrivere un nuovo kernel nella partizione /boot.
Concludo dicendo che dm-verity sicuramente è una nuova feature che aumenterà sensibilmente la sicurezza dei dispositivi per quanto riguarda i malware, ma potrebbe essere controproducente per tutto quel mondo che ruota intorno ai privilegi di root e alle rom custom.
A voi i commenti.