Implementazione della sicurezza

Il team di sicurezza Android riceve regolarmente richieste di informazioni sulla prevenzione di potenziali problemi di sicurezza sui dispositivi Android. Occasionalmente controlliamo anche i dispositivi e informiamo i produttori di dispositivi e i partner interessati di potenziali problemi.

Questa pagina fornisce le migliori pratiche di sicurezza basate sulle nostre esperienze, estendendo la documentazione di progettazione per la sicurezza che abbiamo fornito agli sviluppatori e include dettagli esclusivi per la creazione o l'installazione di software a livello di sistema sui dispositivi.

Per facilitare l'adozione di queste best practice, ove possibile, il team di sicurezza Android incorpora test in Android Compatibility Test Suite (CTS) e Android Lint . Incoraggiamo gli implementatori dei dispositivi a contribuire con test che possano aiutare altri utenti Android (visualizzare i test relativi alla sicurezza in root/cts/tests/tests/security/src/android/security/cts ).

Processo di sviluppo

Utilizza le seguenti best practice nei processi e nell'ambiente di sviluppo.

Revisione del codice sorgente

La revisione del codice sorgente può rilevare un'ampia gamma di problemi di sicurezza, inclusi quelli identificati in questo documento. Android incoraggia fortemente la revisione del codice sorgente sia manuale che automatizzata. Migliori pratiche:

• Esegui Android Lint su tutto il codice dell'applicazione utilizzando Android SDK e correggi eventuali problemi identificati.
• Il codice nativo deve essere analizzato utilizzando uno strumento automatizzato in grado di rilevare problemi di gestione della memoria come overflow del buffer ed errori off-by-one.
• Il sistema di build Android supporta molti dei disinfettanti LLVM, come AddressSanitizer e UnfineBehaviorSanitizer che possono essere utilizzati per questo scopo.

Utilizzando test automatizzati

I test automatizzati possono rilevare un'ampia gamma di problemi di sicurezza, inclusi diversi problemi discussi di seguito. Migliori pratiche:

• Il CTS viene regolarmente aggiornato con test di sicurezza; eseguire la versione più recente di CTS per verificare la compatibilità.
• Esegui regolarmente CTS durante tutto il processo di sviluppo per rilevare tempestivamente i problemi e ridurre i tempi di correzione. Android utilizza CTS come parte dell'integrazione continua nel nostro processo di compilazione automatizzata, che viene creata più volte al giorno.
• I produttori di dispositivi dovrebbero automatizzare i test di sicurezza delle interfacce, compresi i test con input non validi (test fuzz).

Immagini del sistema di firma

La firma dell'immagine del sistema è fondamentale per determinare l'integrità del dispositivo. Migliori pratiche:

• I dispositivi non devono essere firmati con una chiave pubblicamente nota.
• Le chiavi utilizzate per firmare i dispositivi devono essere gestite in modo coerente con le pratiche standard del settore per la gestione delle chiavi sensibili, incluso un modulo di sicurezza hardware (HSM) che fornisce un accesso limitato e verificabile.

Firma delle applicazioni (APK)

Le firme delle applicazioni svolgono un ruolo importante nella sicurezza del dispositivo e vengono utilizzate per i controlli delle autorizzazioni e per gli aggiornamenti software. Quando si seleziona una chiave da utilizzare per firmare le applicazioni, è importante considerare se un'applicazione sarà disponibile solo su un singolo dispositivo o comune su più dispositivi. Migliori pratiche:

• Le domande non devono essere firmate con una chiave pubblicamente nota.
• Le chiavi utilizzate per firmare le applicazioni devono essere gestite in modo coerente con le pratiche standard del settore per la gestione delle chiavi sensibili, incluso un HSM che fornisce un accesso limitato e verificabile.
• Le applicazioni non devono essere firmate con la chiave della piattaforma.
• Le applicazioni con lo stesso nome di pacchetto non devono essere firmate con chiavi diverse. Ciò si verifica spesso quando si crea un'applicazione per dispositivi diversi, soprattutto quando si utilizza la chiave della piattaforma. Se l'applicazione è indipendente dal dispositivo, utilizza la stessa chiave su tutti i dispositivi. Se l'applicazione è specifica del dispositivo, crea nomi di pacchetto univoci per dispositivo e chiave.

Applicazioni di pubblicazione

Google Play offre ai produttori di dispositivi la possibilità di aggiornare le applicazioni senza eseguire un aggiornamento completo del sistema. Ciò può accelerare la risposta ai problemi di sicurezza e la distribuzione di nuove funzionalità, oltre a fornire un modo per garantire che l'applicazione abbia un nome di pacchetto univoco. Migliori pratiche:

• Carica le tue applicazioni su Google Play per consentire aggiornamenti automatici senza richiedere un aggiornamento OTA (over-the-air) completo. Le applicazioni caricate ma non pubblicate non sono direttamente scaricabili dagli utenti ma vengono comunque aggiornate. Gli utenti che hanno precedentemente installato l'app possono reinstallarla e/o installarla su altri dispositivi.
• Creare un nome di pacchetto applicativo chiaramente associato alla propria azienda, ad esempio utilizzando un marchio aziendale.
• Le applicazioni pubblicate dai produttori di dispositivi devono essere caricate su Google Play Store per evitare la falsificazione del nome del pacchetto da parte di utenti di terze parti. Se un produttore di dispositivi installa un'app su un dispositivo senza pubblicarla sul Play Store, un altro sviluppatore potrebbe caricare la stessa app, utilizzare lo stesso nome di pacchetto e modificare i metadati dell'app. Quando l'app viene presentata all'utente, questi metadati non correlati potrebbero creare confusione.

Rispondere agli incidenti

Le parti esterne devono avere la possibilità di contattare i produttori di dispositivi in ​​merito a problemi di sicurezza specifici del dispositivo. Ti consigliamo di creare un indirizzo email accessibile pubblicamente per la gestione degli incidenti di sicurezza. Migliori pratiche:

• Crea un indirizzo security@your-company.com o un indirizzo simile e pubblicizzalo.
• Se vieni a conoscenza di un problema di sicurezza che interessa il sistema operativo Android o i dispositivi Android di più produttori di dispositivi, contatta il team di sicurezza di Android inviando una segnalazione di bug di sicurezza .

Implementazione del prodotto

Utilizzare le seguenti best practice durante l'implementazione di un prodotto.

Isolare i processi root

I processi root sono l'obiettivo più frequente degli attacchi di escalation dei privilegi, quindi ridurre il numero di processi root riduce il rischio di escalation dei privilegi. CTS include un test informativo che elenca i processi root. Migliori pratiche:

• I dispositivi dovrebbero eseguire il codice minimo necessario come root. Ove possibile, utilizza un normale processo Android anziché un processo root. ICS Galaxy Nexus ha solo sei processi root: vold, inetd, zygote, tf_daemon, ueventd e init. Se un processo deve essere eseguito come root su un dispositivo, documenta il processo in una richiesta di funzionalità AOSP in modo che possa essere esaminato pubblicamente.
• Ove possibile, il codice root dovrebbe essere isolato dai dati non attendibili e accessibile tramite IPC. Ad esempio, ridurre la funzionalità root a un piccolo servizio accessibile tramite Binder ed esporre il servizio con autorizzazione di firma a un'applicazione con privilegi bassi o nulli per gestire il traffico di rete.
• I processi root non devono essere in ascolto su un socket di rete.
• I processi root non devono fornire un runtime generico per le applicazioni (ad esempio, una Java VM).

Isolamento delle app di sistema

In generale, le app preinstallate non devono essere eseguite con l'UID del sistema condiviso. Se è necessario, tuttavia, che un'app utilizzi l'UID condiviso del sistema o un altro servizio privilegiato, l'app non deve esportare servizi, ricevitori di trasmissione o fornitori di contenuti a cui possono accedere le app di terze parti installate dagli utenti. Migliori pratiche:

• I dispositivi dovrebbero eseguire il codice minimo necessario come sistema. Ove possibile, utilizza un processo Android con il proprio UID anziché riutilizzare l'UID di sistema.
• Ove possibile, il codice di sistema dovrebbe essere isolato dai dati non attendibili ed esporre IPC solo ad altri processi attendibili.
• I processi di sistema non devono essere in ascolto su un socket di rete.

Processi isolanti

Android Application Sandbox fornisce alle applicazioni un'aspettativa di isolamento da altri processi nel sistema, inclusi processi root e debugger. A meno che il debug non sia abilitato specificatamente dall'applicazione e dall'utente, nessuna applicazione dovrebbe violare tale aspettativa. Migliori pratiche:

• I processi root non devono accedere ai dati all'interno delle cartelle dei dati delle singole applicazioni, a meno che non utilizzino un metodo di debug Android documentato.
• I processi root non devono accedere alla memoria delle applicazioni, a meno che non si utilizzi un metodo di debug Android documentato.
• I dispositivi non devono includere alcuna applicazione che acceda ai dati o alla memoria di altre applicazioni o processi.

Protezione dei file SUID

I nuovi programmi setuid non dovrebbero essere accessibili da programmi non attendibili. I programmi setuid sono stati spesso sede di vulnerabilità che possono essere utilizzate per ottenere l'accesso come root, quindi cercare di ridurre al minimo la disponibilità del programma setuid per le applicazioni non attendibili. Migliori pratiche:

• I processi SUID non devono fornire una shell o una backdoor che possa essere utilizzata per aggirare il modello di sicurezza di Android.
• I programmi SUID non devono essere scrivibili da nessun utente.
• I programmi SUID non dovrebbero essere leggibili o eseguibili da tutti. Creare un gruppo, limitare l'accesso al binario SUID ai membri di quel gruppo e inserire in quel gruppo tutte le applicazioni che dovrebbero essere in grado di eseguire il programma SUID.
• I programmi SUID sono una fonte comune di rooting degli utenti sui dispositivi. Per ridurre questo rischio, i programmi SUID non dovrebbero essere eseguibili dall'utente della shell.

Il verificatore CTS include un test informativo che elenca i file SUID; alcuni file setuid non sono consentiti dai test CTS.

Messa in sicurezza delle prese d'ascolto

I test CTS falliscono quando un dispositivo è in ascolto su qualsiasi porta, su qualsiasi interfaccia. In caso di guasto, Android verifica che siano in uso le seguenti best practice:

• Non dovrebbero essere presenti porte di ascolto sul dispositivo.
• Le porte di ascolto devono poter essere disabilitate senza un OTA. Può trattarsi di una modifica alla configurazione del server o del dispositivo utente.
• I processi root non devono essere in ascolto su nessuna porta.
• I processi di proprietà dell'UID di sistema non devono essere in ascolto su nessuna porta.
• Per gli IPC locali che utilizzano socket, le applicazioni devono utilizzare un socket di dominio UNIX con accesso limitato a un gruppo. Creare un descrittore di file per l'IPC e renderlo +RW per uno specifico gruppo UNIX. Tutte le applicazioni client devono trovarsi all'interno di tale gruppo UNIX.
• Alcuni dispositivi con più processori (ad esempio una radio/modem separato dal processore dell'applicazione) utilizzano socket di rete per comunicare tra i processori. In tali casi, il socket di rete utilizzato per la comunicazione tra processori deve utilizzare un'interfaccia di rete isolata per impedire l'accesso da parte di applicazioni non autorizzate sul dispositivo (ovvero, utilizzare iptables per impedire l'accesso da parte di altre applicazioni sul dispositivo).
• I demoni che gestiscono le porte di ascolto devono essere robusti contro i dati non validi. Google potrebbe condurre test fuzz sulla porta utilizzando un client non autorizzato e, ove possibile, un client autorizzato. Eventuali arresti anomali verranno archiviati come bug con una gravità adeguata.

Dati di registrazione

La registrazione dei dati aumenta il rischio di esposizione di tali dati e riduce le prestazioni del sistema. Si sono verificati numerosi incidenti di pubblica sicurezza a seguito della registrazione di dati sensibili degli utenti da parte di applicazioni installate per impostazione predefinita sui dispositivi Android. Migliori pratiche:

• Le applicazioni o i servizi di sistema non devono registrare i dati forniti da applicazioni di terze parti che potrebbero includere informazioni sensibili.
• Le applicazioni non devono registrare alcuna informazione di identificazione personale (PII) come parte del normale funzionamento.

CTS include test che verificano la presenza di informazioni potenzialmente sensibili nei registri di sistema.

Limitazione dell'accesso alla directory

Le directory scrivibili da tutti possono introdurre punti deboli nella sicurezza e consentire a un'applicazione di rinominare file attendibili, sostituire file o condurre attacchi basati su collegamenti simbolici (gli aggressori possono utilizzare un collegamento simbolico a un file per indurre un programma attendibile a eseguire azioni che non dovrebbe). Le directory scrivibili possono anche impedire che la disinstallazione di un'applicazione ripulisca correttamente tutti i file associati a un'applicazione.

Come migliore pratica, le directory create dal sistema o dagli utenti root non dovrebbero essere scrivibili da tutti. I test CTS aiutano a rafforzare questa best practice testando le directory conosciute.

Protezione dei file di configurazione

Molti driver e servizi si basano su file di configurazione e di dati archiviati in directory come /system/etc e /data . Se questi file vengono elaborati da un processo privilegiato e sono scrivibili da tutti, è possibile che un'app sfrutti una vulnerabilità nel processo creando contenuti dannosi nel file scrivibile da tutti. Migliori pratiche:

• I file di configurazione utilizzati dai processi privilegiati non dovrebbero essere leggibili da tutti.
• I file di configurazione utilizzati dai processi privilegiati non devono essere scrivibili da tutti.

Memorizzazione di librerie di codici nativi

Qualsiasi codice utilizzato dai processi privilegiati del produttore del dispositivo deve trovarsi in /vendor o /system ; questi filesystem sono montati in sola lettura all'avvio. Come procedura consigliata, in questi file system dovrebbero trovarsi anche le librerie utilizzate dal sistema o altre app con privilegi elevati installate sul dispositivo. Ciò può impedire una vulnerabilità della sicurezza che potrebbe consentire a un utente malintenzionato di controllare il codice eseguito da un processo privilegiato.

Limitazione dell'accesso ai driver del dispositivo

Solo il codice attendibile dovrebbe avere accesso diretto ai driver. Ove possibile, l'architettura preferita è fornire un demone a scopo singolo che invii le chiamate al driver e limiti l'accesso del driver a quel demone. Come best practice, i nodi del dispositivo driver non dovrebbero essere leggibili o scrivibili da tutti. I test CTS aiutano a rafforzare questa procedura consigliata verificando la presenza di istanze note di driver esposti.

Disabilitare ADB

Android debug bridge (adb) è un prezioso strumento di sviluppo e debug, ma è progettato per l'uso in ambienti controllati e sicuri e non deve essere abilitato per l'uso generale. Migliori pratiche:

• ADB deve essere disabilitato per impostazione predefinita.
• ADB deve richiedere all'utente di accenderlo prima di accettare le connessioni.

Sblocco bootloader

Molti dispositivi Android supportano lo sblocco, consentendo al proprietario del dispositivo di modificare la partizione di sistema e/o installare un sistema operativo personalizzato. I casi d'uso comuni includono l'installazione di una ROM di terze parti e l'esecuzione dello sviluppo a livello di sistema sul dispositivo. Ad esempio, il proprietario di un dispositivo Google Nexus può eseguire fastboot oem unlock per avviare il processo di sblocco, che presenta all'utente il seguente messaggio:

Come best practice, i dispositivi Android sbloccabili devono cancellare in modo sicuro tutti i dati dell'utente prima di essere sbloccati. La mancata eliminazione corretta di tutti i dati allo sblocco può consentire a un utente malintenzionato fisicamente vicino di ottenere l'accesso non autorizzato ai dati riservati degli utenti Android. Per impedire la divulgazione dei dati dell'utente, un dispositivo che supporta lo sblocco deve implementarlo correttamente (abbiamo riscontrato numerosi casi in cui i produttori di dispositivi hanno implementato in modo errato lo sblocco). Un processo di sblocco correttamente implementato ha le seguenti proprietà:

• Quando il comando di sblocco viene confermato dall'utente, il dispositivo deve avviare un'immediata cancellazione dei dati. Il flag unlocked non deve essere impostato fino al completamento dell'eliminazione sicura.
• Se non è possibile completare un'eliminazione sicura, il dispositivo deve rimanere in uno stato bloccato.
• Se supportato dal dispositivo a blocchi sottostante, è necessario utilizzare ioctl(BLKSECDISCARD) o equivalente. Per i dispositivi eMMC, ciò significa utilizzare un comando Secure Erase o Secure Trim. Per eMMC 4.5 e versioni successive, ciò significa utilizzare una normale operazione di cancellazione o taglio seguita da un'operazione di sanitizzazione.
• Se BLKSECDISCARD non è supportato dal dispositivo a blocchi sottostante, è necessario utilizzare invece ioctl(BLKDISCARD) . Sui dispositivi eMMC, questa è una normale operazione di Trim.
• Se BLKDISCARD non è supportato, è accettabile sovrascrivere i dispositivi a blocchi con tutti zeri.
• Un utente finale deve avere la possibilità di richiedere che i dati dell'utente vengano cancellati prima di eseguire il flashing di una partizione. Ad esempio, sui dispositivi Nexus, ciò avviene tramite il comando fastboot oem lock .
• Un dispositivo può registrare, tramite efuse o meccanismo simile, se un dispositivo è stato sbloccato e/o ribloccato.

Questi requisiti garantiscono che tutti i dati vengano distrutti al completamento di un'operazione di sblocco. La mancata implementazione di queste protezioni è considerata una vulnerabilità della sicurezza di livello moderato.

Un dispositivo sbloccato può essere successivamente ribloccato utilizzando il comando fastboot oem lock . Il blocco del bootloader fornisce la stessa protezione dei dati utente con il nuovo sistema operativo personalizzato disponibile con il sistema operativo originale del produttore del dispositivo (ad esempio, i dati utente verranno cancellati se il dispositivo viene sbloccato nuovamente).