Utilizzo di codice nativo

Categoria OWASP: MASVS-CODE: Code Quality

Panoramica

Le applicazioni Android possono sfruttare il codice nativo scritto in linguaggi come C e C++ per funzionalità specifiche. Tuttavia, quando un'applicazione utilizza la Java Native Interface (JNI) per interagire con questo codice nativo, si espone potenzialmente a vulnerabilità come overflow del buffer e altri problemi che potrebbero essere presenti nell'implementazione del codice nativo.

Impatto

Nonostante gli impatti molto positivi come l'ottimizzazione delle prestazioni e l'offuscamento, l'utilizzo di codice nativo nelle applicazioni Android può avere un impatto negativo sulla sicurezza. I linguaggi di codice nativo come C/C++ non dispongono delle funzionalità di sicurezza della memoria di Java/Kotlin, il che li rende vulnerabili a problemi come overflow del buffer, errori use-after-free e altri problemi di danneggiamento della memoria, con conseguenti arresti anomali o esecuzione di codice arbitrario. Inoltre, se esiste una vulnerabilità nel componente di codice nativo, può potenzialmente compromettere l'intera applicazione, anche se il resto è scritto in modo sicuro in Java.

Mitigazioni

Guida allo sviluppo e alla programmazione

  • Linee guida per la programmazione sicura: per i progetti C/C++, rispetta gli standard di programmazione sicura consolidati (ad es. CERT, OWASP) per mitigare le vulnerabilità come overflow del buffer, overflow di interi e attacchi di tipo format string. Dai la priorità alle librerie come Abseil, note per qualità e sicurezza. Se possibile, valuta l'adozione di linguaggi sicuri per la memoria come Rust, che offrono prestazioni paragonabili a C/C++.
  • Convalida dell'input: convalida rigorosamente tutti i dati di input ricevuti da fonti esterne, inclusi input utente, dati di rete e file, per impedire attacchi di iniezione e altre vulnerabilità.

Rafforzare le opzioni di compilazione

Le librerie native che utilizzano il formato ELF possono essere protette da una serie di vulnerabilità attivando meccanismi di protezione come la protezione dello stack (Canary), la riallocazione di sola lettura (RELRO), la prevenzione dell'esecuzione dei dati (NX) e gli eseguibili indipendenti dalla posizione (PIE). Le opzioni di compilazione dell'Android NDK attivano già tutte queste protezioni per impostazione predefinita.

Per verificare l'implementazione di questi meccanismi di sicurezza all'interno di un binario, puoi utilizzare strumenti come hardening-check o pwntools.

Bash

$ pwn checksec --file path/to/libnativecode.so
    Arch:     aarch64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

Verifica che le librerie di terze parti non siano vulnerabili

Quando scegli librerie di terze parti, dai la priorità a quelle con una solida reputazione nella community di sviluppo. Risorse come l'indice SDK Google Play possono aiutarti a identificare librerie affidabili e apprezzate. Assicurati di mantenere aggiornate le librerie alle versioni più recenti e di cercare in modo proattivo eventuali vulnerabilità note correlate utilizzando risorse come i database di Exploit-DB. Una ricerca sul web utilizzando parole chiave come [library_name] vulnerability o [library_name] CVE può rivelare informazioni critiche sulla sicurezza.

Risorse