Nova Técnica para Identificar Bugs de Software
Um novo método foca nas interações do ambiente pra encontrar aqueles bugs de software que são difíceis de achar.
― 7 min ler
Índice
Bugs em software são um problema comum, e muitas vezes é difícil encontrá-los. Enquanto a maioria dos bugs é identificada ao testar várias entradas em um programa, alguns bugs só aparecem quando um programa roda em ambientes específicos. Esses ambientes incluem componentes como bancos de dados, arquivos e outros recursos com os quais o software interage durante sua operação.
Este artigo discute uma nova técnica voltada para encontrar esses bugs escorregadios em software criando ambientes operacionais especiais onde esses bugs podem ser acionados. A ideia principal é observar como um programa interage com seu ambiente e ajustar esse ambiente de um jeito que possa expor bugs ocultos. A abordagem usa um método chamado mutação guiada por cobertura, que significa que ela rastreia quais partes do programa estão sendo testadas e altera o ambiente de acordo.
O Problema com Bugs
Quando pensamos em bugs de software, geralmente imaginamos erros no código que levam a falhas ou comportamentos inesperados. Esses bugs são normalmente encontrados ao rodar o software com várias entradas. Contudo, nem todos os bugs são causados por entradas ruins; alguns dependem do ambiente do programa. Um ambiente pode ser qualquer coisa externa ao software, como arquivos de configuração, bancos de dados ou até mesmo a forma como o programa está configurado em uma máquina.
Por exemplo, se um atacante consegue controlar o ambiente de um programa, ele pode explorar bugs que os desenvolvedores nunca imaginaram. Isso pode levar a sérios problemas de segurança, como acesso não autorizado a dados sensíveis ou até mesmo assumir o controle de todo o sistema. Para prevenir esses ataques, é crucial identificar e corrigir esses bugs que dependem do ambiente.
A Abordagem
Para encontrar esses bugs ocultos, a abordagem proposta captura como os programas interagem com seu ambiente através de um processo de monitoramento e modificação de recursos. Aqui estão os principais passos envolvidos:
Monitoramento de Chamadas de Sistema: As ações do programa, especificamente as chamadas de sistema que ele faz para acessar recursos do ambiente, são monitoradas. Isso ajuda a identificar quais recursos estão sendo acessados e como.
Capturando Recursos: Quando o programa é executado com uma entrada, os recursos específicos que ele usa são salvos. Isso inclui fazer cópias de bancos de dados, arquivos e configurações.
Mutando Ambientes: Esses recursos copiados são então ligeiramente alterados para criar novas versões do ambiente. Mudando esses recursos de formas pequenas, os novos ambientes podem ser testados para ver se levam a um comportamento diferente no programa.
Rastreando Cobertura: Quaisquer novos ambientes que levam a uma cobertura aumentada durante os testes são mantidos para exploração futura. Esse rastreamento garante que os testes se concentrem em áreas do programa que podem não ter sido examinadas adequadamente.
Relatório Automatizado: Se algum bug for encontrado durante esse processo, ele é reportado para análise posterior. Isso permite uma resposta mais rápida na correção desses problemas.
Impacto no Mundo Real
A abordagem foi testada em vários projetos de software de código aberto conhecidos. Durante esses testes, o método conseguiu identificar múltiplos bugs que não haviam sido encontrados usando métodos tradicionais. Focando em como o programa interage com seu ambiente, tornou-se possível revelar problemas que passaram despercebidos.
Uma das principais vantagens desse método é sua capacidade de trabalhar com programas existentes sem precisar de mudanças extensas no código. Observando e modificando o ambiente, ele oferece uma forma flexível de testar software em várias condições.
Benefícios dos Testes Baseados em Ambiente
A necessidade de estratégias de testes aprimoradas está se tornando mais evidente à medida que os sistemas de software se tornam cada vez mais complexos. Os testes baseados em ambiente oferecem vários benefícios:
Descobre Bugs Ocultos: Ao se concentrar no ambiente, essa técnica permite identificar bugs que não são influenciados por entradas padrão. Esses bugs podem ser críticos, especialmente em aplicações sensíveis à segurança.
Cobertura Aprimorada: Esse método resulta em aumento da cobertura do código sendo testado. Mais partes do programa são avaliadas, o que pode levar a uma maior chance de descobrir bugs.
Flexibilidade: Como essa abordagem não depende apenas de entradas pré-definidas, ela pode se adaptar a vários ambientes e situações inesperadas que podem surgir durante a operação.
Iniciativas de Ciência Aberta: Ao compartilhar as ferramentas e métodos usados para essa pesquisa, a comunidade se beneficia das descobertas, permitindo que outros repliquem e ampliem o trabalho.
Resultados Experimentais
O método foi implementado em uma variedade de projetos de software, e os resultados foram promissores. Aqui estão algumas descobertas-chave:
Descoberta de Bugs: Os testes revelaram inúmeros bugs anteriormente não descobertos em diferentes programas. Os bugs estavam principalmente relacionados a como o software lidava com seu ambiente.
Melhoria na Cobertura de Branches: A nova técnica alcançou uma melhoria notável na cobertura de branches em comparação com métodos de teste convencionais. Isso significa que mais áreas do código foram executadas durante os testes, levando a uma maior probabilidade de identificar bugs.
Métricas de Performance: Embora houvesse um certo overhead em termos de performance devido ao monitoramento adicionado, a compensação foi considerada aceitável quando se leva em conta o aumento significativo na descoberta de bugs e na cobertura de código.
Desafios e Limitações
Apesar do potencial, essa abordagem enfrenta desafios:
Realismo dos Ambientes: Um obstáculo é garantir que os ambientes gerados sejam realistas o suficiente para refletir com precisão cenários do mundo real. Se os ambientes não forem plausíveis, isso pode levar a resultados enganosos.
Interações Complexas: O software pode ter interações complexas com numerosos recursos, tornando difícil rastrear todas as possíveis variações durante os testes.
Exaustão de Recursos: Às vezes, um ambiente pode se esgotar devido a muitas mudanças ou execuções falhadas, exigindo um reset para garantir que os testes possam continuar de forma completa.
Falsos Positivos: Também é possível que os testes resultem em falsos positivos, onde um bug parece estar presente devido a mudanças no ambiente, mas não representa verdadeiramente um defeito no software.
Direções Futuras
Olhando para frente, há várias avenidas para melhoria e exploração:
Frameworks de Teste Automatizados: Desenvolver mais ferramentas automatizadas para ajudar a criar e manipular ambientes poderia agilizar o processo.
Integração com Ferramentas Existentes: Encontrar maneiras de integrar esse método com ferramentas de teste existentes poderia aumentar sua adoção generalizada.
Aplicações em Domínios Cruzados: Aplicar esse modelo além de aplicações baseadas em rede para outros tipos de software poderia ajudar a descobrir diferentes tipos de bugs.
Colaboração da Comunidade: Incentivar a colaboração dentro da comunidade de desenvolvimento de software para compartilhar insights e melhorias relacionadas a esse método de teste poderia resultar em novas descobertas em confiabilidade de software.
Conclusão
O desafio de encontrar e corrigir bugs em software continua a ser crítico à medida que a tecnologia avança. Ao focar no ambiente em que os programas operam, os desenvolvedores podem descobrir bugs ocultos que os testes baseados em entradas tradicionais poderiam perder. A abordagem discutida aqui oferece uma forma estruturada de monitorar, capturar e modificar ambientes de programas, levando a uma melhor qualidade e segurança do software.
As técnicas introduzidas fornecem um caminho promissor na luta contínua contra bugs de software, garantindo que as futuras aplicações sejam mais robustas e seguras contra ameaças potenciais. À medida que essa área de pesquisa evolui, ela tem o potencial de mudar a forma como os desenvolvedores abordam os testes de software em vários domínios, abrindo caminho para aplicativos mais seguros e confiáveis.
Título: Finding Bug-Inducing Program Environments
Resumo: Some bugs cannot be exposed by program inputs, but only by certain program environments. During execution, most programs access various resources, like databases, files, or devices, that are external to the program and thus part of the program's environment. In this paper, we present a coverage-guided, mutation-based environment synthesis approach of bug-inducing program environments. Specifically, we observe that programs interact with their environment via dedicated system calls and propose to intercept these system calls (i) to capture the resources accessed during the first execution of an input as initial program environment, and (ii) mutate copies of these resources during subsequent executions of that input to generate slightly changed program environments. Any generated environment that is observed to increase coverage is added to the corpus of environment seeds and becomes subject to further fuzzing. Bug-inducing program environments are reported to the user. Experiments demonstrate the effectiveness of our approach. We implemented a prototype called AFLChaos which found bugs in the resource-handling code of five (5) of the seven (7) open source projects in our benchmark set (incl. OpenSSL). Automatically, AFLChaos generated environments consisting of bug-inducing databases used for storing information, bug-inducing multimedia files used for streaming, bug-inducing cryptographic keys used for encryption, and bug-inducing configuration files used to configure the program. To support open science, we publish the experimental infrastructure, our tool, and all data.
Autores: Zahra Mirzamomen, Marcel Böhme
Última atualização: 2023-04-19 00:00:00
Idioma: English
Fonte URL: https://arxiv.org/abs/2304.10044
Fonte PDF: https://arxiv.org/pdf/2304.10044
Licença: https://creativecommons.org/licenses/by/4.0/
Alterações: Este resumo foi elaborado com a assistência da AI e pode conter imprecisões. Para obter informações exactas, consulte os documentos originais ligados aqui.
Obrigado ao arxiv pela utilização da sua interoperabilidade de acesso aberto.
Ligações de referência
- https://anonymous.4open.science/r/AFLChaos
- https://docs.nvidia.com/clara/deploy/RunningReferencePipeline.html
- https://book.orthanc-server.com/faq/dicom-tls.html
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dcmtk
- https://hmarco.org/bugs/dcmtk-3.6.1-privilege-escalation.html
- https://github.com/DCMTK/DCMTK/blob/master/dcmqrdb/docs/dcmqrcnf.txt
- https://github.com/DCMTK/dcmtk/blob/master/dcmqrdb/libsrc/dcmqrcnf.cc
- https://github.com/DCMTK/dcmtk/blob/7f8564c/dcmqrdb/libsrc/dcmqrcnf.cc
- https://rdrr.io/cran/effsize/man/VD.A.html
- https://support.dcmtk.org/redmine/issues/1026
- https://github.com/kamailio/kamailio/commit/f0cea1a7c03e400b4398795c2d8b0f7e45d1dfb5
- https://github.com/openssl/openssl/commit/6ab6ecfd6d2d659326f427dceb1b65ae1b4b012b
- https://ctan.org/pkg/pifont
- https://ctan.org/pkg/tcolorbox
- https://dl.acm.org/ccs.cfm