Como o teste fuzz fortalece a segurança do dispositivo IoT

O teste fuzz representa um importante meio disponível para engenheiros encontrarem pontos fracos em sistemas embarcados dispositivos e deve ser considerado para o reforço das interfaces do dispositivo IoT.
Com a proliferação de dispositivos IoT, vêm o aumento dos ataques à segurança incorporada. Historicamente, os engenheiros de sistema embarcado têm ignorado a segurança da camada do dispositivo, apesar das muitas áreas dos dispositivos incorporados que são vulneráveis ​​a bugs. Portas seriais, interfaces de rádio e até interfaces de programação / depuração podem ser exploradas por hackers. O teste de difusão representa um importante local disponível para engenheiros para encontrar pontos fracos em dispositivos incorporados e deve ser considerado para fortalecer interfaces de dispositivos de IoT.

O que é teste fuzz?

O teste fuzz é como o mítico milhão de macacos digitando aleatoriamente para escrever Shakespeare. Na prática, as obras de ficção requerem muitas combinações aleatórias para produzir uma frase simples, mas para sistemas embarcados, precisamos apenas alterar algumas letras de uma frase válida.

Numerosas ferramentas comerciais e de código aberto estão disponíveis para implementar ataques fuzz. Essas ferramentas geram strings de bytes aleatórios, também chamados de vetores fuzz ou vetores de ataque, e os submetem à interface em teste, acompanhando o comportamento resultante que poderia significar um bug.

O teste de difusão é um jogo de números, mas não podemos tentar um número infinito de entradas possíveis. Em vez disso, nos concentramos na otimização do tempo de teste, maximizando a taxa de envio do vetor fuzz, a eficácia dos vetores fuzz e os algoritmos de detecção de bug.

Conceitos de teste fuzz

Como muitas ferramentas de teste fuzz foram projetadas para testar aplicativos de PC, é mais fácil adaptá-las se você executar seu código incorporado como um aplicativo de PC compilado nativamente. A execução de código embutido em um PC traz uma grande vantagem de desempenho, mas tem duas desvantagens. Primeiro, os microprocessadores de PC não reagem da mesma forma que os microcontroladores incorporados. Em segundo lugar, devemos reescrever qualquer código que toque no hardware. No entanto, na prática, as vantagens de rodar em um PC superam as desvantagens. A verdadeira barreira é a dificuldade de portar o código para compilar nativamente no PC.

Como sabemos quando um vetor fuzz dispara um bug? Uma falha é fácil de detectar, mas é mais difícil identificar os vetores difusos que causam uma reinicialização. Bugs de estouro de memória ou escrita de ponteiro perdido - o tipo de bug mais valioso para hackers - são quase impossíveis de discernir de fora do sistema, pois normalmente não resultam em um travamento ou reinicialização.

Muitos compiladores modernos, como GCC e Clang, possuem um recurso chamado sanitização de memória. Isso marca os blocos de memória como limpos ou sujos, dependendo se eles estão em uso e sinaliza qualquer tentativa de acessar a memória suja. No entanto, a limpeza da memória consome ciclos de flash, RAM e CPU, dificultando a execução em dispositivos incorporados. Portanto, em vez disso, podemos testar um subconjunto de código, construir uma versão do dispositivo com mais recursos ou usar um PC.

A eficácia de um teste pode ser avaliada pela quantidade de código exercido. Aqui também, os compiladores podem rastrear o uso de memória empregando chamadas de sub-rotina de migalhas de pão. A biblioteca de cobertura de código mantém uma tabela de valores de uso para cada caminho de código, incrementando-os quando a migalha de pão é executada.

No entanto, os números de cobertura do código são difíceis de interpretar para o teste de difusão incorporado porque grande parte do código é inacessível aos vetores de difusão; por exemplo, um driver de dispositivo para um periférico executado independentemente da interface. Portanto, é difícil definir "cobertura de código completa" para sistemas incorporados - talvez apenas 20% do código incorporado esteja acessível. A cobertura de código também consome grandes quantidades de flash, RAM e ciclos de CPU e precisaria de hardware especializado ou de um PC para ser executado.

Relatório de bug

Quando o teste de difusão encontra um vetor que causa comportamento indesejado, precisamos de informações detalhadas. Onde o bug aconteceu? Qual é o estado da pilha de chamadas? Qual é o tipo específico de bug? Todas essas informações ajudam a fazer a triagem e, eventualmente, corrigir o bug.

A triagem de bugs é crucial no teste de difusão. Novos projetos fuzz geralmente encontram muitos bugs, e precisamos de uma maneira automática para determinar sua gravidade. Além disso, os bugs de fuzz tendem a bloquear os bugs porque geralmente mascaram bugs adicionais mais adiante no caminho do código. Precisamos de uma solução rápida para os problemas que surgem durante o teste de difusão.

Os clientes incorporados não estão tão dispostos a revelar suas informações como os PCs. Normalmente, uma falha fará com que o dispositivo seja reiniciado e reiniciado. Embora isso seja desejado em campo, ele apaga o estado do dispositivo, tornando difícil saber se uma falha ocorreu, onde ou por que aconteceu, ou o caminho do código percorrido. O engenheiro deve encontrar um vetor de reprodução consistente e, em seguida, usar um depurador para rastrear o mau comportamento e localizar o bug.

No teste fuzz, um teste pode render milhares de vetores de falha para alguns bugs, dando a falsa impressão de um sistema com bugs. É importante determinar rapidamente quais vetores estão associados ao mesmo bug subjacente. Para dispositivos incorporados, a localização da falha em si é normalmente exclusiva para o bug e geralmente não é necessário para encontrar o rastreamento completo da pilha de chamadas.

Teste de difusão contínua

Devido à natureza estocástica dos testes de difusão, executá-los por períodos mais longos aumenta as chances de encontrar problemas. Mas nenhum plano de projeto poderia absorver atrasos de um longo ciclo de teste fuzz no final do desenvolvimento.

Na prática, o teste de difusão começaria em seu próprio ramo após o processo de lançamento. Qualquer bug recém-descoberto seria corrigido no branch local, para que o teste pudesse continuar sem os novos bugs bloqueando a descoberta de bug adicional. Como parte do ciclo de lançamento, os bugs descobertos em versões anteriores do teste fuzz seriam avaliados para inclusão em novos lançamentos. Finalmente, os vetores fuzz que descobriram um bug devem ser adicionados aos processos normais de garantia de qualidade para verificar a correção e garantir que esses bugs não sejam reintroduzidos inadvertidamente no código.

Devemos executar testes de difusão de dispositivos em diferentes cenários; por exemplo, um dispositivo responde às solicitações de conexão de maneira diferente se estiver em rede. É impraticável executar o teste de difusão em todos os cenários possíveis, mas podemos incluir testes de difusão para cada valor de estado possível. Por exemplo, execute testes de difusão com cada tipo de dispositivo diferente, mantendo as outras variáveis ​​iguais. Em seguida, execute valores diferentes para outra variável, como o estado de conectividade da rede, para um tipo de dispositivo.

Arquiteturas de teste fuzz

Duas arquiteturas de teste fuzz proeminentes são fuzzing direcionado, onde os vetores fuzz são especificados por um engenheiro antes do teste, e teste fuzz guiado por cobertura, onde a ferramenta fuzz começa com um conjunto inicial de vetores de teste e os transforma automaticamente com base em quão bem os pacotes penetram o código.

Além disso, nem todo código será executado em um PC, e desenvolver um simulador de PC para um aplicativo incorporado pode ser impraticável, dependendo do que está sendo testado.

Abaixo está um resumo de quatro arquiteturas de teste fuzz:

• Teste direto de interface em hardware embutido - executando a imagem de produção normal no dispositivo embutido com pacotes fuzz injetados na interface
• Teste de injeção de pacote (pilha) - chamando rotinas de pacote de entrada diretamente, sem ter que exercitar a interface pelo ar
• Fuzzing direcionado com um simulador - usando técnicas de simulação baseadas em PC para desenvolver e testar código incorporado
• Fuzzing guiado por cobertura com um simulador (mostrado como Libfuzz abaixo)

Vários testadores fuzz

Depois de bloquear um dispositivo incorporado com bloqueio de interface de depuração e inicialização segura, precisamos considerar o teste de difusão das interfaces do dispositivo. Muitas das mesmas ferramentas e conceitos usados ​​para proteger servidores da web podem ser adaptados para uso com dispositivos incorporados.

Use a ferramenta certa para o trabalho. O fuzzing guiado por cobertura é necessário para o teste de fuzz contínuo, mas se o seu código só executa em hardware integrado, os fuzzers direcionados podem ser uma boa escolha para fornecer algum nível de cobertura de teste de fuzz.

Finalmente, você deve empregar vários fuzz testers em tantos cenários quanto possível, pois cada um testará o dispositivo de maneira ligeiramente diferente, maximizando a cobertura e, portanto, a segurança do seu dispositivo incorporado.

>> Este artigo foi publicado originalmente em nosso site irmão, EDN.