nccgroup/triforceaflFuzzing AFL/QEMU com emulação de sistema completo.
Novo: Para aqueles que desejam brincar com TriforceAFL e TLSF, Richard Johnson criou um Dockerfile que instala ambos (e até compila um kernel Linux para você). Ele está disponível aqui https://hub.docker.com/r/moflow/afl-triforce/tags/.
Também novo: o afl-tmin agora funciona com o forkserver!
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Esta é uma versão corrigida do AFL que suporta fuzzing de sistema completo usando QEMU. O QEMU incluído foi atualizado para permitir o rastreamento de ramificações ao executar um emulador de sistema para x86_64. Instruções extras foram adicionadas para iniciar o forkserver do AFL, definir configurações de fuzzing e marcar o início e o fim dos casos de teste.
Nota: nem todas as ferramentas do AFL foram testadas com as novas alterações. Estas ferramentas passaram por alguns testes:
Para construir:
make
Para obter um mapa de cobertura:
echo hello > /tmp/hello
./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello
cat coverage.txt
Para fuzzar:
egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic
mkdir inputs
echo hello > inputs/hello
./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@
(Nota: diferente de quando se usa a opção "-Q", você deve especificar a linha de comando completa para afl-qemu-system-trace ao usar a opção "-QQ").
Para mais detalhes sobre como usar esta versão modificada do AFL, veja nosso fuzzer de syscalls do Linux em https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Novas flags do AFL: -QQ - use qemu em emulação de sistema completo em vez do modo de usuário (-Q)
Novas flags do QEMU: -aflFile - O nome do arquivo que contém as entradas do fuzzer -aflPanicAddr - Um endereço de pânico do kernel para detecção de pânico -aflDmesgAddr - Endereço no kernel Linux da função de registro (logging) do dmesg para detectar registro e interceptar mensagens de log
Novas instruções do QEMU: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Start AFL's fork server. After this point each test will run in a separate forked child. If enableTicks is non-zero, QEMU will re-enable the CPUs timer after forking a child, otherwise it will not be enabled. edi=2 getWork(esi=ptr, edx=sz) Fill ptr[0..sz] with the next input test case. Returns the actual size filled (<= sz). edi=3 startWork(esi=ptr) Tell AFL to start tracing. The argument points to a buffer with two quadwords giving the start and end address of the code to trace. Instructions outside of this range are not traced. edi=4 doneWork(esi=exitCode) Tell AFL that the test case has completed. If a panic is detected, AFL will stop the test case immediately. Otherwise it will run until doneWork is called. The exitCode specified is returned to AFL. (The code can, but currently does not, OR in the value 64 to all exit codes if any dmesg logs were detected during the test case.)
Novo driver de bloco do QEMU: -drive filename=privmem: Este driver de bloco mantém a imagem do drive em memória copy-on-write para que as alterações nunca sejam persistidas no disco. Alterações feitas por um caso de teste são isoladas de outros casos de teste.
Escrito e mantido por Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. Todos os direitos reservados. Liberado sob os termos e condições da Licença Apache, Versão 2.0.
Para novas versões e informações adicionais, confira: http://lcamtuf.coredump.cx/afl/
Para trocar ideias com outros usuários ou ser notificado sobre grandes novidades, envie um e-mail para [email protected].
** Veja QuickStartGuide.txt se você não tiver tempo para ler este arquivo. **
Fuzzing é uma das estratégias mais poderosas e comprovadas para identificar problemas de segurança em software do mundo real; é responsável pela grande maioria dos bugs de execução remota de código e escalonamento de privilégios encontrados até hoje em software crítico para a segurança.
Infelizmente, o fuzzing também é relativamente superficial; mutações cegas e aleatórias tornam muito improvável alcançar certos caminhos de código no software testado, deixando algumas vulnerabilidades firmemente fora do alcance dessa técnica.
Houve inúmeras tentativas de resolver esse problema. Uma das primeiras abordagens - pioneira de Tavis Ormandy - é a destilação de corpus. O método depende de sinais de cobertura para selecionar um subconjunto de sementes interessantes de um corpus massivo e de alta qualidade de arquivos candidatos e, em seguida, submetê-los a fuzzing por meios tradicionais. A abordagem funciona excepcionalmente bem, mas exige que esse corpus esteja prontamente disponível. Além disso, as medições de cobertura de blocos fornecem apenas uma compreensão muito simplista do estado do programa e são menos úteis para orientar o esforço de fuzzing a longo prazo.
Outras pesquisas mais sofisticadas concentraram-se em técnicas como análise de fluxo de programa ("execução concólica"), execução simbólica ou análise estática. Todos esses métodos são extremamente promissores em ambientes experimentais, mas tendem a sofrer de problemas de confiabilidade e desempenho em usos práticos - e atualmente não oferecem uma alternativa viável às técnicas de fuzzing "dumb".
O American Fuzzy Lop é um fuzzer de força bruta combinado com um algoritmo genético extremamente simples, mas sólido como uma rocha, guiado por instrumentação. Ele usa uma forma modificada de cobertura de arestas para capturar sem esforço mudanças sutis e em escala local no fluxo de controle do programa.
Simplificando um pouco, o algoritmo geral pode ser resumido como:
Carregar os casos de teste iniciais fornecidos pelo usuário na fila,
Pegar o próximo arquivo de entrada da fila,
Tentar reduzir o caso de teste ao menor tamanho que não altere o comportamento medido do programa,
Mutar repetidamente o arquivo usando uma variedade equilibrada e bem pesquisada de estratégias tradicionais de fuzzing,
Se alguma das mutações geradas resultar em uma nova transição de estado registrada pela instrumentação, adicionar a saída mutada como uma nova entrada na fila.
Ir para 2.
Os casos de teste descobertos também são periodicamente eliminados para remover aqueles que foram superados por descobertas mais novas e de maior cobertura; e passam por várias outras etapas de minimização de esforço orientadas por instrumentação.
Como resultado secundário do processo de fuzzing, a ferramenta cria um corpus pequeno e autocontido de casos de teste interessantes. Eles são extremamente úteis para semear outros regimes de teste que exigem muito trabalho ou recursos - por exemplo, para testes de estresse em navegadores, aplicativos de escritório, suítes de gráficos ou ferramentas de código fechado.
O fuzzer é amplamente testado para entregar desempenho imediato muito superior ao fuzzing cego ou a ferramentas baseadas apenas em cobertura.
Quando o código-fonte está disponível, a instrumentação pode ser injetada por uma ferramenta complementar que funciona como substituto imediato do gcc ou clang em qualquer processo de build padrão para código de terceiros.
A instrumentação tem um impacto de desempenho bastante modesto; em conjunto com outras otimizações implementadas pelo afl-fuzz, a maioria dos programas pode ser submetida a fuzzing tão rápido ou até mais rápido do que com ferramentas tradicionais.
A maneira correta de recompilar o programa alvo pode variar dependendo das especificidades do processo de build, mas uma abordagem quase universal seria:
$ CC=/path/to/afl/afl-gcc ./configure $ make clean all
Para programas C++, você também vai querer definir CXX=/path/to/afl/afl-g++.
Os wrappers do clang (afl-clang e afl-clang++) podem ser usados da mesma forma; usuários do clang também podem optar por aproveitar um modo de instrumentação de maior desempenho, conforme descrito em llvm_mode/README.llvm.
Ao testar bibliotecas, você precisa encontrar ou escrever um programa simples que leia dados de stdin ou de um arquivo e os passe para a biblioteca testada. Nesse caso, é essencial vincular esse executável a uma versão estática da biblioteca instrumentada, ou garantir que o arquivo .so correto seja carregado em tempo de execução (geralmente definindo LD_LIBRARY_PATH). A opção mais simples é um build estático, geralmente possível via:
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
Definir AFL_HARDEN=1 ao chamar 'make' fará com que o wrapper do CC ative automaticamente opções de endurecimento de código que facilitam a detecção de bugs simples de memória.
PS. Usuários do ASAN são aconselhados a revisar o arquivo notes_for_asan.txt para obter advertências importantes.
Quando o código-fonte NÃO está disponível, o fuzzer oferece suporte experimental para instrumentação rápida e em tempo real de binários caixa-preta. Isso é feito com uma versão do QEMU executando no modo menos conhecido de "emulação de espaço do usuário".
O QEMU é um projeto separado do AFL, mas você pode compilar convenientemente o recurso fazendo:
$ cd qemu_mode $ ./build_qemu_support.sh
Para instruções adicionais e advertências, veja qemu_mode/README.qemu.
O modo é aproximadamente 2 a 5 vezes mais lento que a instrumentação em tempo de compilação, é menos propício à paralelização e pode ter algumas outras peculiaridades.
Para operar corretamente, o fuzzer exige um ou mais arquivos iniciais que contenham um bom exemplo dos dados de entrada normalmente esperados pelo aplicativo alvo. Há duas regras básicas:
Mantenha os arquivos pequenos. Abaixo de 1 kB é ideal, embora não seja estritamente necessário. Para uma discussão sobre por que o tamanho importa, veja perf_tips.txt.
Use vários casos de teste somente se eles forem funcionalmente diferentes entre si. Não faz sentido usar cinquenta fotos de férias diferentes para fazer fuzzing em uma biblioteca de imagens.
Você pode encontrar muitos bons exemplos de arquivos iniciais no subdiretório testcases/ que acompanha esta ferramenta.
PS. Se um grande corpus de dados estiver disponível para triagem, você pode querer usar o utilitário afl-cmin para identificar um subconjunto de arquivos funcionalmente distintos que exercitam diferentes caminhos de código no binário alvo.
O processo de fuzzing em si é realizado pelo utilitário afl-fuzz. Este programa requer um diretório somente leitura com casos de teste iniciais, um local separado para armazenar suas descobertas, além de um caminho para o binário a ser testado.
Para binários alvo que aceitam entrada diretamente de stdin, a sintaxe usual é:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
Para programas que recebem entrada de um arquivo, use '@@' para marcar, na linha de comando do alvo, o local onde o nome do arquivo de entrada deve ser colocado. O fuzzer fará essa substituição para você:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
Você também pode usar a opção -f para que os dados mutados sejam gravados em um arquivo específico. Isso é útil se o programa espera uma extensão de arquivo específica ou algo assim.
Binários não instrumentados podem ser submetidos a fuzzing no modo QEMU (adicione -Q na linha de comando) ou em um modo tradicional de fuzzer cego (especifique -n).
Você pode usar -t e -m para substituir o tempo limite e o limite de memória padrão do processo executado; exemplos raros de alvos que podem precisar dessas configurações alteradas incluem compiladores e decodificadores de vídeo.
Dicas para otimizar o desempenho do fuzzing são discutidas em perf_tips.txt.
Observe que o afl-fuzz começa executando uma série de etapas determinísticas de fuzzing, que podem levar vários dias. Se você quiser resultados rápidos e sujos imediatamente, semelhantes ao zzuf ou honggfuzz, adicione a opção -d à linha de comando.
Consulte o arquivo status_screen.txt para obter informações sobre como interpretar as estatísticas exibidas e monitorar a saúde do processo. Certifique-se de consultar este arquivo especialmente se algum elemento da interface estiver destacado em vermelho.
O processo de fuzzing continuará até você pressionar Ctrl-C. No mínimo, você deve permitir que o fuzzer complete um ciclo de fila, o que pode levar de algumas horas a uma semana ou mais.
Há três subdiretórios criados dentro do diretório de saída e atualizados em tempo real:
queue/ - casos de teste para cada caminho de execução distinto, além de todos os arquivos iniciais fornecidos pelo usuário. Este é o corpus sintetizado mencionado na seção 2.
Antes de usar este corpus para qualquer outra finalidade, você
pode reduzi-lo a um tamanho menor usando a ferramenta afl-cmin.
A ferramenta encontrará um subconjunto menor de arquivos que
oferecem cobertura de arestas equivalente.
crashes/ - casos de teste únicos que fazem o programa testado receber um sinal fatal (por exemplo, SIGSEGV, SIGILL, SIGABRT). As entradas são agrupadas pelo sinal recebido.
hangs/ - casos de teste únicos que fazem o programa testado atingir o tempo limite. Observe que, quando as configurações padrão (agressivas) de tempo limite estão em vigor, isso pode ser um pouco ruidoso devido a picos de latência e outros fenômenos naturais.
Crashes e hangs são considerados "únicos" se os caminhos de execução associados envolverem quaisquer transições de estado não vistas em falhas registradas anteriormente. Se um único bug puder ser alcançado de várias maneiras, haverá alguma inflação na contagem no início do processo, mas isso deve diminuir rapidamente.
Os nomes de arquivo de crashes e hangs são correlacionados com as entradas pai da fila que não apresentam falhas. Isso deve ajudar na depuração.
Quando você não consegue reproduzir um crash encontrado pelo afl-fuzz, a causa mais provável é que você não está definindo o mesmo limite de memória usado pela ferramenta. Tente:
$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Altere LIMIT_MB para corresponder ao parâmetro -m passado ao afl-fuzz. No OpenBSD, mude também -Sv para -Sd.
Qualquer diretório de saída existente também pode ser usado para retomar trabalhos interrompidos; tente:
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]
Se você tiver o gnuplot instalado, também pode gerar alguns gráficos bonitos para qualquer tarefa de fuzzing ativa usando o afl-plot. Para um exemplo de como isso se parece, veja http://lcamtuf.coredump.cx/afl/plot/.
Cada instância do afl-fuzz ocupa aproximadamente um núcleo. Isso significa que, em sistemas multi-core, a paralelização é necessária para utilizar totalmente o hardware. Para dicas sobre como fazer fuzzing em um alvo comum em vários núcleos ou várias máquinas em rede, consulte parallel_fuzzing.txt.
Por padrão, o mecanismo de mutação do afl-fuzz é otimizado para formatos de dados compactos - por exemplo, imagens, multimídia, dados compactados, sintaxe de expressões regulares ou scripts de shell. Ele é um pouco menos adequado para linguagens com verbosidade particularmente extensa e redundante - notavelmente incluindo HTML, SQL ou JavaScript.
Para evitar o trabalho de criar ferramentas que compreendem a sintaxe, o afl-fuzz oferece uma maneira de semear o processo de fuzzing com um dicionário opcional de palavras-chave de linguagem, cabeçalhos mágicos ou outros tokens especiais associados ao tipo de dados alvo - e usá-lo para reconstruir a gramática subjacente em tempo real:
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
Para usar esse recurso, primeiro você precisa criar um dicionário em um dos dois formatos discutidos em testcases/README.testcases; e então apontar o fuzzer para ele por meio da opção -x na linha de comando.
Não há como fornecer descrições mais estruturadas da sintaxe subjacente, mas o fuzzer provavelmente descobrirá parte disso com base apenas no feedback da instrumentação. Isso funciona na prática, por exemplo:
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
PS. Mesmo quando nenhum dicionário explícito é fornecido, o afl-fuzz tentará extrair tokens de sintaxe existentes no corpus de entrada observando a instrumentação de perto durante flips determinísticos de bytes. Isso funciona para alguns tipos de parsers e gramáticas, mas não é tão bom quanto o modo -x.
O agrupamento de crashes com base em cobertura geralmente produz um pequeno conjunto de dados que pode ser rapidamente triado manualmente ou com um script GDB ou Valgrind muito simples. Todo crash também é rastreável até seu caso de teste pai sem crash na fila, facilitando o diagnóstico de falhas.
Dito isso, é importante reconhecer que alguns crashes de fuzzing podem ser difíceis de avaliar rapidamente quanto à explorabilidade sem muito trabalho de depuração e análise de código. Para auxiliar nessa tarefa, o afl-fuzz suporta um modo muito exclusivo de "exploração de crash" habilitado com a opção -C.
Nesse modo, o fuzzer recebe um ou mais casos de teste com crash como entrada e usa suas estratégias de fuzzing orientadas por feedback para enumerar muito rapidamente todos os caminhos de código que podem ser alcançados no programa, mantendo-o no estado de crash.
Mutações que não resultam em crash são rejeitadas; o mesmo ocorre com qualquer alteração que não afete o caminho de execução.
A saída é um pequeno corpus de arquivos que pode ser examinado muito rapidamente para ver qual grau de controle o atacante tem sobre o endereço da falha, ou se é possível ultrapassar uma leitura fora dos limites inicial - e ver o que está por baixo.
Ah, mais uma coisa: para minimização de casos de teste, experimente o afl-tmin. A ferramenta pode ser operada de uma maneira muito simples:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
A ferramenta funciona tanto com casos de teste com crash quanto sem crash. No modo de crash, ela aceita binários instrumentados e não instrumentados. No modo sem crash, o minimizador depende da instrumentação padrão do AFL para simplificar o arquivo sem alterar o caminho de execução.
O minimizador aceita a sintaxe -m, -t, -f e @@ de maneira compatível com o afl-fuzz.
Outra adição recente ao AFL é a ferramenta afl-analyze. Ela recebe um arquivo de entrada, tenta inverter bytes sequencialmente e observa o comportamento do programa testado. Em seguida, codifica por cores a entrada com base em quais seções parecem ser críticas e quais não são; embora não seja à prova de balas, muitas vezes pode oferecer insights rápidos sobre formatos de arquivo complexos. Mais informações sobre seu funcionamento podem ser encontradas perto do final de technical_details.txt.
Tenha em mente que, semelhantemente a muitas outras tarefas que exigem muita computação, o fuzzing pode sobrecarregar seu hardware e o sistema operacional. Em particular:
Sua CPU ficará quente e precisará de resfriamento adequado. Na maioria dos casos, se o resfriamento for insuficiente ou parar de funcionar corretamente, as velocidades da CPU serão reduzidas automaticamente. Dito isso, especialmente ao fazer fuzzing em hardware menos adequado (laptops, smartphones, etc), não é totalmente impossível que algo exploda.
Programas alvo podem acabar consumindo gigabytes de memória de forma errática ou enchendo o espaço em disco com arquivos inúteis. O AFL tenta impor limites básicos de memória, mas não pode evitar todos os possíveis contratempos. A conclusão é que você não deve fazer fuzzing em sistemas onde a perspectiva de perda de dados não seja um risco aceitável.- Fuzzing envolve bilhões de leituras e escritas no sistema de arquivos. Em sistemas modernos, isso geralmente será fortemente armazenado em cache, resultando em E/S "física" bastante modesta — mas há muitos fatores que podem alterar essa equação. É sua responsabilidade monitorar possíveis problemas; com E/S muito intensa, a vida útil de muitos HDDs e SSDs pode ser reduzida.
Uma boa maneira de monitorar a E/S de disco no Linux é o comando 'iostat':
$ iostat -d 3 -x -k [...ID do disco opcional...]
Aqui estão algumas das ressalvas mais importantes para o AFL:
O AFL detecta falhas verificando se o primeiro processo gerado morreu devido a um sinal (SIGSEGV, SIGABRT, etc.). Programas que instalam manipuladores personalizados para esses sinais podem precisar ter o código relevante comentado. Da mesma forma, falhas em processos filhos gerados pelo alvo fuzzeado podem escapar da detecção, a menos que você adicione manualmente algum código para capturá-las.
Como em qualquer outra ferramenta de força bruta, o fuzzer oferece cobertura limitada se criptografia, somas de verificação, assinaturas criptográficas ou compressão forem usadas para envolver totalmente o formato de dados real a ser testado.
Para contornar isso, você pode comentar as verificações relevantes (veja experimental/libpng_no_checksum/ para inspiração); se isso não for possível, você também pode escrever um pós-processador, conforme explicado em experimental/post_library/.
Há algumas desvantagens infelizes com ASAN e binários de 64 bits. Isso não se deve a nenhuma falha específica do afl-fuzz; veja notes_for_asan.txt para dicas.
Não há suporte direto para fuzzing de serviços de rede, daemons em segundo plano ou aplicativos interativos que exigem interação com a IU para funcionar. Você pode precisar fazer alterações simples no código para que eles se comportem de uma maneira mais tradicional. O Preeny também pode oferecer uma opção relativamente simples — veja: https://github.com/zardus/preeny
Algumas dicas úteis para modificar serviços baseados em rede também podem ser encontradas em: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
O AFL não gera dados de cobertura legíveis por humanos. Se você quiser monitorar a cobertura, use o afl-cov do Michael Rash: https://github.com/mrash/afl-cov
Além disso, veja INSTALL para dicas específicas de plataforma.
Muitas das melhorias no afl-fuzz não seriam possíveis sem feedback, relatórios de bugs ou patches de:
Jann Horn Hanno Boeck Felix Groebert Jakub Wilk Richard W. M. Jones Alexander Cherepanov Tom Ritter Hovik Manucharyan Sebastian Roschke Eberhard Mattes Padraig Brady Ben Laurie @dronesec Luca Barbato Tobias Ospelt Thomas Jarosch Martin Carpenter Mudge Zatko Joe Zbiciak Ryan Govostes Michael Rash William Robinet Jonathan Gray Filipe Cabecinhas Nico Weber Jodie Cunningham Andrew Griffiths Parker Thompson Jonathan Neuschfer Tyler Nighswander Ben Nagy Samir Aguiar Aidan Thornton Aleksandar Nikolich Sam Hakim Laszlo Szekeres David A. Wheeler Turo Lamminen Andreas Stieger Richard Godbee Louis Dassy teor2345 Alex Moneger Dmitry Vyukov Keegan McAllister Kostya Serebryany Richo Healey Martijn Bogaard rc0r Jonathan Foote Christian Holler Dominique Pelle Jacek Wielemborek Leo Barnes Jeremy Barnes Jeff Trull Guillaume Endignoux ilovezfs Daniel Godas-Lopez Franjo Ivancic
Obrigado!
Dúvidas? Preocupações? Relatórios de bugs? O autor geralmente pode ser contatado em [email protected].
Há também uma lista de discussão para o projeto; para se inscrever, envie um e-mail para [email protected]. Ou, se preferir consultar os arquivos primeiro, tente:
https://groups.google.com/group/afl-users
PS. Se você deseja enviar código bruto para ser incorporado ao projeto, esteja ciente de que os direitos autorais sobre a maior parte do AFL são reivindicados pelo Google. Embora você retenha os direitos autorais sobre suas contribuições, eles pedem que as pessoas concordem com um CLA simples primeiro:
https://cla.developers.google.com/clas
Desculpe pelo transtorno. É claro que nenhum CLA é necessário para solicitações de recursos ou relatórios de bugs.