O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Fuzz com libFuzzer

Fuzzing, que é simplesmente fornecer informações potencialmente inválidas, inesperadas ou aleatórias como entrada para um programa, é uma forma extremamente eficaz de encontrar bugs grandes sistemas de software e é parte importante do processo de ciclo de vida.

O sistema de compilação do Android é compatível com fuzzing com a inclusão de libFuzzer do do projeto de infraestrutura do compilador do LLVM. O LibFuzzer é vinculado à biblioteca em teste e processa todas as entradas. seleção, mutação e relatório de erros que ocorrem durante uma sessão de fuzzing. Limpadores do LLVM são usados para ajudar na detecção de corrupção de memória e código métricas de cobertura.

Este artigo apresenta uma introdução ao libFuzzer no Android e como executar um build instrumentado. Ele também inclui instruções para gravar, executar e personalizar fuzzers.

Configuração e criação

Para garantir que uma imagem funcione em um dispositivo, faça o download uma fábrica imagem e atualize o dispositivo. Como alternativa, você pode fazer o download da origem do AOSP e siga o exemplo de configuração e criação abaixo.

Exemplo de configuração

Este exemplo presume que o dispositivo de destino é um Pixel (taimen) e está já preparado para a depuração USB (aosp_taimen-userdebug). Você pode fazer o download de outros binários do Pixel de Drivers Binaries.

mkdir ~/bin
export PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
repo init -u https://android.googlesource.com/platform/manifest -b main
repo sync -c -j8
wget https://dl.google.com/dl/android/aosp/google_devices-taimen-qq1a.191205.008-f4537f93.tgz
tar xvf google_devices-taimen-qq1a.191205.008-f4537f93.tgz
./extract-google_devices-taimen.sh
wget https://dl.google.com/dl/android/aosp/qcom-taimen-qq1a.191205.008-760afa6e.tgz
tar xvf qcom-taimen-qq1a.191205.008-760afa6e.tgz
./extract-qcom-taimen.sh
. build/envsetup.sh
lunch aosp_taimen-userdebug

Exemplo de build

A primeira etapa para executar destinos de fuzz é conseguir uma nova imagem do sistema. Qa é ter pelo menos a versão de desenvolvimento mais recente do Android.

Execute o build inicial emitindo:
```
m
```
Para que você possa atualizar seu dispositivo, inicialize-o no modo fastboot usando o adequado combinação de teclas.
Desbloqueie o carregador de inicialização e atualize a imagem recém-compilada com o seguinte: comandos
```
fastboot oem unlock
fastboot flashall
```

O dispositivo de destino vai estar pronto para o fuzzing do libFuzzer.

Criar um fuzzer

Para ilustrar como escrever um fuzzer de ponta a ponta usando o libFuzzer no Android, use o código vulnerável como um caso de teste. Isso ajuda a testar o fuzzer. Verifique se se tudo está funcionando corretamente e ilustrar como são os dados de falha.

Esta é a função de teste.

#include <stdint.h>
#include <stddef.h>
bool FuzzMe(const char *data, size_t dataSize) {
    return dataSize >= 3  &&
           data[0] == 'F' &&
           data[1] == 'U' &&
           data[2] == 'Z' &&
           data[3] == 'Z';  // ← Out of bounds access
}

Para criar e executar esse fuzzer de testes:

Um destino de fuzz consiste em dois arquivos: um arquivo de build e o código-fonte de destino do fuzz. Crie seus arquivos em um local ao lado da biblioteca que você está misturando. Dê ao fuzzer que descreve o que o fuzzer faz.
Crie um destino de fuzz usando o libFuzzer. O destino de fuzz é uma função que pega um blob de dados de um tamanho especificado e o passa para a função a ser desconexos. Este é um fuzzer básico para a função de teste vulnerável:
```
#include <stddef.h>
#include <stdint.h>

extern "C" int LLVMFuzzerTestOneInput(const char *data, size_t size) {
  // ...
  // Use the data to call the library you are fuzzing.
  // ...
  return FuzzMe(data, size);
}
```

Instrua o sistema de compilação do Android a criar o binário fuzzer. Para criar o fuzzer, adicione este código ao arquivo Android.bp:

cc_fuzz {
  name: "fuzz_me_fuzzer",
  srcs: [
    "fuzz_me_fuzzer.cpp",
  ],
  // If the fuzzer has a dependent library, uncomment the following section and
  // include it.
  // static_libs: [
  //   "libfoo", // Dependent library
  // ],
  //
  // The advanced features below allow you to package your corpus and
  // dictionary files during building. You can find more information about
  // these features at:
  //  - Corpus: https://llvm.org/docs/LibFuzzer.html#corpus
  //  - Dictionaries: https://llvm.org/docs/LibFuzzer.html#dictionaries
  // These features are not required for fuzzing, but are highly recommended
  // to gain extra coverage.
  // To include a corpus folder, uncomment the following line.
  // corpus: ["corpus/*"],
  // To include a dictionary, uncomment the following line.
  // dictionary: "fuzz_me_fuzzer.dict",
}

Para criar o fuzzer para execução no alvo (dispositivo):
```
SANITIZE_TARGET=hwaddress m fuzz_me_fuzzer
```
Para fazer o fuzzer executar no host:
```
SANITIZE_HOST=address m fuzz_me_fuzzer
```

Por conveniência, defina algumas variáveis de shell contendo o caminho para seu fuzz target e o nome do binário, do arquivo de build que você escreveu.

export FUZZER_NAME=your_fuzz_target

Depois de seguir essas etapas, você terá um fuzzer criado. O padrão o local do fuzzer (neste exemplo de build do Pixel) é:

$ANDROID_PRODUCT_OUT/data/fuzz/$TARGET_ARCH/$FUZZER_NAME/$FUZZER_NAME para dispositivo.

$ANDROID_HOST_OUT/fuzz/$TARGET_ARCH/$FUZZER_NAME/$FUZZER_NAME para o organizador.

Executar o fuzzer no host

Adicione ao arquivo de build Android.bp:

host_supported: true,

Isso só pode ser aplicado se a biblioteca que você quer mesclar é host suporte.

Execute o fuzzer no host simplesmente executando o binário do fuzzer criado:

$ANDROID_HOST_OUT/fuzz/x86_64/$FUZZER_NAME/$FUZZER_NAME

Executar o fuzzer no dispositivo

Queremos copiar isso para seu dispositivo usando adb.

Para fazer o upload desses arquivos para um diretório no dispositivo, execute estes comandos:
```
adb root
adb sync data
```

Execute o fuzzer de teste no dispositivo com este comando:

adb shell /data/fuzz/$(get_build_var TARGET_ARCH)/$FUZZER_NAME/$FUZZER_NAME \
  /data/fuzz/$(get_build_var TARGET_ARCH)/$FUZZER_NAME/corpus

Isso resulta em uma saída semelhante ao exemplo abaixo.

INFO: Seed: 913963180
INFO: Loaded 2 modules   (16039 inline 8-bit counters): 16033 [0x7041769b88, 0x704176da29), 6 [0x60e00f4df0, 0x60e00f4df6),
INFO: Loaded 2 PC tables (16039 PCs): 16033 [0x704176da30,0x70417ac440), 6 [0x60e00f4df8,0x60e00f4e58),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
#2	INITED cov: 5 ft: 5 corp: 1/1b exec/s: 0 rss: 24Mb
#10	NEW    cov: 6 ft: 6 corp: 2/4b lim: 4 exec/s: 0 rss: 24Mb L: 3/3 MS: 3 CopyPart-ChangeByte-InsertByte-
#712	NEW    cov: 7 ft: 7 corp: 3/9b lim: 8 exec/s: 0 rss: 24Mb L: 5/5 MS: 2 InsertByte-InsertByte-
#744	REDUCE cov: 7 ft: 7 corp: 3/7b lim: 8 exec/s: 0 rss: 25Mb L: 3/3 MS: 2 ShuffleBytes-EraseBytes-
#990	REDUCE cov: 8 ft: 8 corp: 4/10b lim: 8 exec/s: 0 rss: 25Mb L: 3/3 MS: 1 ChangeByte-
==18631==ERROR: HWAddressSanitizer: tag-mismatch on address 0x0041e00b4183 at pc 0x0060e00c5144
READ of size 1 at 0x0041e00b4183 tags: f8/03 (ptr/mem) in thread T0
    #0 0x60e00c5140  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0xf140)
    #1 0x60e00ca130  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x14130)
    #2 0x60e00c9b8c  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x13b8c)
    #3 0x60e00cb188  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15188)
    #4 0x60e00cbdec  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15dec)
    #5 0x60e00d8fbc  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x22fbc)
    #6 0x60e00f0a98  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x3aa98)
    #7 0x7041b75d34  (/data/fuzz/arm64/lib/libc.so+0xa9d34)

[0x0041e00b4180,0x0041e00b41a0) is a small allocated heap chunk; size: 32 offset: 3
0x0041e00b4183 is located 0 bytes to the right of 3-byte region [0x0041e00b4180,0x0041e00b4183)
allocated here:
    #0 0x70418392bc  (/data/fuzz/arm64/lib/libclang_rt.hwasan-aarch64-android.so+0x212bc)
    #1 0x60e00ca040  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x14040)
    #2 0x60e00c9b8c  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x13b8c)
    #3 0x60e00cb188  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15188)
    #4 0x60e00cbdec  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15dec)
    #5 0x60e00d8fbc  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x22fbc)
    #6 0x60e00f0a98  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x3aa98)
    #7 0x7041b75d34  (/data/fuzz/arm64/lib/libc.so+0xa9d34)
    #8 0x60e00c504c  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0xf04c)
    #9 0x70431aa9c4  (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x519c4)

Thread: T1 0x006700006000 stack: [0x007040c55000,0x007040d4ecc0) sz: 1023168 tls: [0x000000000000,0x000000000000)
Thread: T0 0x006700002000 stack: [0x007fe51f3000,0x007fe59f3000) sz: 8388608 tls: [0x000000000000,0x000000000000)
Memory tags around the buggy address (one tag corresponds to 16 bytes):
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   08  00  cf  08  dc  08  cd  08  b9  08  1a  1a  0b  00  04  3f
=> 27  00  08  00  bd  bd  2d  07 [03] 73  66  66  27  27  20  f6 <=
   5b  5b  87  87  03  00  01  00  4f  04  24  24  03  39  2c  2c
   05  00  04  00  be  be  85  85  04  00  4a  4a  05  05  5f  5f
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
   00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
   04  ..  ..  cf  ..  dc  ..  cd  ..  b9  ..  ..  3f  ..  57  ..
=> ..  ..  21  ..  ..  ..  ..  2d [f8] ..  ..  ..  ..  ..  ..  .. <=
   ..  ..  ..  ..  9c  ..  e2  ..  ..  4f  ..  ..  99  ..  ..  ..
See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags
Registers where the failure occurred (pc 0x0060e00c5144):
    x0  f8000041e00b4183  x1  000000000000005a  x2  0000000000000006  x3  000000704176d9c0
    x4  00000060e00f4df6  x5  0000000000000004  x6  0000000000000046  x7  000000000000005a
    x8  00000060e00f4df0  x9  0000006800000000  x10 0000000000000001  x11 00000060e0126a00
    x12 0000000000000001  x13 0000000000000231  x14 0000000000000000  x15 000e81434c909ede
    x16 0000007041838b14  x17 0000000000000003  x18 0000007042b80000  x19 f8000041e00b4180
    x20 0000006800000000  x21 000000000000005a  x22 24000056e00b4000  x23 00000060e00f5200
    x24 00000060e0128c88  x25 00000060e0128c20  x26 00000060e0128000  x27 00000060e0128000
    x28 0000007fe59f16e0  x29 0000007fe59f1400  x30 00000060e00c5144
SUMMARY: HWAddressSanitizer: tag-mismatch (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0xf140)
MS: 1 ChangeByte-; base unit: e09f9c158989c56012ccd88111b82f778a816eae
0x46,0x55,0x5a,
FUZ
artifact_prefix='./'; Test unit written to ./crash-0eb8e4ed029b774d80f2b66408203801cb982a60
Base64: RlVa

Na saída de exemplo, a falha foi causada por fuzz_me_fuzzer.cpp. na linha 10:

      data[3] == 'Z';  // :(

Esta é uma leitura simples e fora dos limites se data tiver o comprimento 3.

Depois de executar o fuzzer, a saída geralmente resulta em falha e é salva no corpus e recebe um ID. Na saída do exemplo, isso é crash-0eb8e4ed029b774d80f2b66408203801cb982a60:

Para recuperar informações de falhas ao fazer fuzzing no dispositivo, emita este comando: especificando seu ID de falha:

adb pull /data/fuzz/arm64/fuzz_me_fuzzer/corpus/CRASH_ID

Para salvar os casos de teste no diretório correto, use o comando corpus (como no exemplo acima) ou use o argumento artifact_prefix (por exemplo, "-artifact_prefix=/data/fuzz/where/my/crashes/go").

Ao executar o fuzzing no host, as informações da falha aparecem na pasta de falhas do pasta local onde o fuzzer está sendo executado.

Gerar cobertura de linha

A cobertura de linha é muito útil para os desenvolvedores, pois eles podem identificar áreas no código que não são cobrir e atualizar os fuzzers para atingir essas áreas em futuras execuções de fuzzing.

Para gerar relatórios de cobertura de fuzzer, execute as seguintes etapas :
```
CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS='*' make ${FUZZER_NAME}
```

Depois de enviar o fuzzer e as dependências dele para o dispositivo, execute o destino do fuzz com LLVM_PROFILE_FILE da seguinte maneira:

DEVICE_TRACE_PATH=/data/fuzz/$(get_build_var TARGET_ARCH)/${FUZZER_NAME}/data.profraw
adb shell LLVM_PROFILE_FILE=${DEVICE_TRACE_PATH} /data/fuzz/$(get_build_var TARGET_ARCH)/${FUZZER_NAME}/${FUZZER_NAME} -runs=1000

Produza o relatório de cobertura extraindo primeiro o arquivo .profraw do dispositivo e, em seguida, gerando o relatório html para uma pasta chamada cover-html, conforme mostrado abaixo:

adb pull ${DEVICE_TRACE_PATH} data.profraw
llvm-profdata merge --sparse data.profraw --output data.profdata
llvm-cov show --format=html --instr-profile=data.profdata \
  symbols/data/fuzz/$(get_build_var TARGET_ARCH)/${FUZZER_NAME}/${FUZZER_NAME} \
  --output-dir=coverage-html --path-equivalence=/proc/self/cwd/,$ANDROID_BUILD_TOP

Para mais informações sobre o libFuzzer, consulte a documentação upstream.