A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.

Questa pagina è stata tradotta dall'API Cloud Translation.

Android Security AutoRepro
Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Il plug-in Gradle AutoRepro è basato sul test harness Android Trade Federation per testare tutti i dispositivi Android per i test delle patch di sicurezza rispetto alle vulnerabilità nel Android Security Bulletin. Questi test sono esclusivamente per le correzioni associate o che verranno associate a una vulnerabilità ed esposizione comuni (CVE).

Il plug-in consente lo sviluppo di test Tradefed al di fuori dell'albero di origine Android utilizzando Android Studio o l'SDK Android standard. Include tutte le utilità necessarie per creare ed eseguire un test Tradefed.

Viene utilizzato principalmente per inviare proof-of-concept riproducibili automaticamente per il Vulnerability Reward Program di Android.

Scarica l'esempio di AutoRepro

Prerequisiti

Le istruzioni sono fornite per un PC Linux a 64 bit.

Android Studio Ladybug o versioni successive: puoi installarlo anche dal gestore dei pacchetti della tua distribuzione.
Strumenti della piattaforma Android SDK (adb, fastboot): devono essere installati e trovarsi in $PATH (ovvero, dovresti essere in grado di eseguire adb dalla riga di comando). Il modo più semplice per installare gli strumenti della piattaforma è utilizzare il gestore dei pacchetti della tua distribuzione.
- Se utilizzi il gestore SDK di Android Studio anziché gli strumenti di piattaforma autonomi, ricordati di aggiungere la directory platform-tools dell'SDK a $PATH per lo sviluppo a riga di comando.
AAPT2. - Può essere installato anche utilizzando il gestore dei pacchetti della tua distribuzione.
Java JDK 21 o versioni successive, compatibile con l'SDK Android e Gradle.

Iniziare a utilizzare Android Studio

Dopo aver estratto l'esempio o il modello, apri la directory in Android Studio come progetto esistente e attendi il completamento della sincronizzazione di Gradle. Esistono diverse configurazioni di esecuzione di Android Studio preconfigurate.

Attività Gradle:

assembleSubmissionSources: assembla i file di origine per il file ZIP inviato.
assembleSubmissionZip: assembla il file ZIP da inviare per il caricamento.
copyInvocationResultsToSubmission: copia i risultati delle invocazioni di TradeFed precedenti nella directory delle origini di invio di AutoRepro per contribuire al processo di revisione. Tieni presente che contiene i log sia dell'host sia del dispositivo. Esamina i contenuti prima o dopo l'esecuzione.

Configurazioni di esecuzione di Android Studio per l'invocazione di AutoRepro:

autorepro_nonroot_arm64
autorepro_nonroot_x86_64
autorepro_root_arm64
autorepro_root_x86_64

Le configurazioni del programma di avvio sono nel moduloautorepro_{device_root}_{device_arch}. In genere è preferibile utilizzare nonroot perché le vulnerabilità che richiedono i privilegi di root sono meno gravi. Tuttavia, l'utilizzo del privilegio di accesso come utente root per eseguire la configurazione o la pulizia può essere accettabile a condizione che sia chiaramente documentato e sia generalmente accettato come stato non root valido. Ad esempio, è accettabile utilizzare i permessi di root per simulare l'invio di SMS al dispositivo per evitare di dover utilizzare un secondo dispositivo e più schede SIM.

Verrà lanciato Tradefed per il tuo test. Tradefed attende che un dispositivo valido sia collegato, quindi assicurati che sia collegato e che il debug ADB sia autorizzato.

Scrivere un test AutoRepro

Un test AutoRepro è composto da tre parti e da tre plug-in Gradle corrispondenti:

Plug-in Gradle id("com.android.security.autorepro.javahosttest") Il singolo test Tradefed lato host che interagisce con il dispositivo tramite ADB. L'esempio lo utilizza nella directory submission/hostTest/.
Plug-in Gradle id("com.android.security.autorepro.apptest") Un APK di app o servizio installato sul dispositivo tramite adb install e avviato dal test lato host. L'app o il servizio può anche contenere un proprio insieme di asserzioni JUnit che viene segnalato al runner lato host. L'esempio lo utilizza nelle directory submission/appTest/ e.
Plug-in Gradle id("com.android.security.autorepro.ndktest") Un attacco di proof-of-concept facoltativo basato su NDK che viene inviato al dispositivo tramite adb push ed eseguito dal test lato host. L'esempio lo utilizza nella directory submission/ndkTest/.

Un tipico flusso di test AutoRepro segue in genere uno dei due schemi:

App di test strumentata:
1. Il test lato host spinge un APK costituito da un servizio o un'app instrumentata sul dispositivo.
2. Il test lato host avvia i test JUnit lato dispositivo che sono inclusi con l'APK tramite runDeviceTest().
3. I test JUnit lato dispositivo toccano i pulsanti e osservano l'app utilizzando UIAutomator o accedono in altro modo alle API Android in modo da rivelare vulnerabilità di sicurezza.
4. L'esito positivo o negativo dei test JUnit lato dispositivo viene restituito al test lato host, che può essere utilizzato per determinare se il test è andato a buon fine o meno. Il messaggio di errore deve contenere informazioni dettagliate sul motivo dell'errore dell'affermazione e oggetti, valori, eccezioni, tracce dello stack o altri elementi specifici come prova della vulnerabilità.
Proof of concept NDK:
1. Il test lato host spinge e avvia un eseguibile Linux sul dispositivo.
2. Il programma nativo si arresta in modo anomalo o restituisce un codice di uscita specifico.
3. Il test lato host controlla gli arresti anomali, esamina il backtrace di logcat o cerca il codice di uscita specifico per determinare se l'attacco è andato a buon fine. Il messaggio di errore deve contenere informazioni dettagliate sul motivo dell'errore dell'affermazione e eventuali strutture, valori, stacktrace o altri elementi specifici come prova della vulnerabilità.

È anche possibile una combinazione dei due pattern (ad esempio, l'esecuzione di un programma nativo in combinazione con i test lato dispositivo). Sono disponibili anche altri framework di instrumentation, ad esempio frida-inject. Per maggiori dettagli, consulta la documentazione di riferimento di Security Test Suite e la documentazione di riferimento di TradeFed.

Il mio attacco di prova del concetto non richiede un'app di test o un file eseguibile nativo

Per la maggior parte dei test non è necessaria sia un'app lato dispositivo sia un file eseguibile nativo.

Se il test non prevede l'utilizzo di una funzionalità, elimina le directory dei sottoprogetti gradle non necessarie.

Il mio attacco di prova del concetto coinvolge una seconda app/un secondo servizio

Aggiungi tutti i sottoprogetti Gradle con i plug-in AutoRepro che vuoi.

Invia il test AutoRepro

Per includere i risultati dei test del tuo dispositivo nell'invio:

Se vuoi, esegui l'attività Gradle clean per eliminare le vecchie esecuzioni di test.
Esegui la configurazione di esecuzione di AutoRepro appropriata per richiamare Tradefed per il test e raccogliere log e risultati.
Esegui l'attività copyInvocationResultsToSubmission per copiare i log e i risultati nella directory delle origini dei contenuti inviati.

Esegui assembleSubmissionZip per creare il submission/build/autorepro-submission.zip file. Carica questo file insieme alla tua segnalazione al Vulnerability Reward Program di Android. Assicurati che l'allegato corrisponda al pattern *autorepro-submission*.zip e che sia caricato con il report iniziale. Il caricamento in ritardo delle segnalazioni influisce sulla nostra capacità di esaminarle correttamente.