IMChecker
1.0.0
Qui, grupo imchecker, entre em contato conosco em [email protected]
As bibliotecas oferecem funcionalidade reutilizável por meio de interfaces de programação de aplicativos (APIs) com restrições de uso, como condições de chamada ou pedidos. As violações de restrição, ou seja, os usos de API, geralmente levam a insetos e problemas de segurança. Embora os pesquisadores tenham desenvolvido vários detectores de uso de API nas últimas décadas, estudos recentes mostram que o uso indevido da API é predominante em projetos do mundo real. As abordagens existentes sofrem com o problema de uso escasso (ou seja, bugs que raramente ocorrem) ou relatam alarmes falsos devido à semântica imprecisa. Para superar essas limitações, apresentamos o IMCHECKER para detectar efetivamente os bugs de uso da API. O principal insight por trás do IMCHECKER é uma técnica de análise estática direcionada a restrições alimentada por uma linguagem específica de domínio (DSL) para especificar restrições de uso da API. Ao estudar os bugs de uso da API do mundo real, propomos o IMSPEC DSL, que abrange a maioria dos tipos de restrições de uso da API e permite especificação simples, mas precisa. Além disso, projetamos e implementamos o IMCHECKER para analisar automaticamente a IMSPEC em alvos de corrente e empregamos um mecanismo de análise estática para identificar possíveis usos incorretos da API e podar falsos positivos com a semântica rica. Instantamos o IMCHECKER para programas C e o avaliamos em benchmarks amplamente utilizados e programas em larga escala.
Atualmente, 75 bugs anteriormente desconhecidos foram encontrados e 61 foram confirmados e corrigidos no kernel Linux, OpenSSL e pacotes no Ubuntu 16.04. Estamos tentando o nosso melhor para aplicar o IMCHECKER a mais programas. Carregamos os detalhes em avaliação_data/new_bugs
Nosso manuscrito de pesquisa e manuscrito da ferramenta estão sob processo de revisão do ICSE'19. Nós os carregaremos assim que o processo de revisão terminar. (Bem, você pode nos enviar um e -mail para acessá -los apenas com fins acadêmicos.)
Nosso vídeo de demonstração de ferramentas está disponível na versão em inglês: https://youtu.be/ygdxeyoevim Versão chinesa: https://www.youtube.com/watch?v=3zanegtwuto https://pan.baid.com/s/1digq0r6wk5shmlot.
Uso de nossas ferramentas em ferramentas/readme.md
O IMCHECKER ainda está em desenvolvimento e contém muitos bugs e listas de tarefas. Quaisquer bugs ou solicitações de recursos, sinta -se à vontade para nos enviar um e -mail para [email protected] ou abrir problemas.
Para entender melhor que tipo de bugs de uso da API ocorrem em projetos C reais e como os desenvolvedores os correm na prática, estudamos manualmente os históricos de versão de dois anos de três projetos de código aberto e meio ano do Linux-Kernel em 2017, como mostrado na tabela a seguir. Essas histórias são escolhidas devido ao desenvolvimento contínuo e porque são frequentemente mencionadas em diversos trabalhos de detecção de insetos. No total, estudamos aproximadamente 13,57m LOC e 51,1k.
| Projeto | Loc | Período estudado | TOTAL COMITEIROS | Correções de bug | API usa mal |
|---|---|---|---|---|---|
| Curl | 112,8k | 20160101-20171231 | 2613 | 135 | 38 |
| Gnutls | 35.8k | 20160101-20171231 | 2769 | 86 | 30 |
| OpenSSL | 454.2k | 20160101-20171231 | 6487 | 344 | 115 |
| Linux | 12,96m | 20170701-20171231 | 39295 | 995 | 362 |
| Total | 15.57m | Dois anos | 51.1k | 1560 | 509 |
Para ajudar os leitores a extrair a mensagem de cometa, alterações de arquivos e patch arquivos, abrimos nossa ferramenta Gitgrabber . Também carregamos todas as confirmações relacionadas a bugs de uso da API nos assuntos estudados para uso posterior.
Os leitores podem encontrá -los na pasta empírica_study. Qualquer problema no Gitgrabber, não hesite em entrar em contato conosco!
Selecionamos um benchmark amplamente usado, ou seja, Juliet Test Suite v1.3 e dois programas do mundo real em suas mais recentes versões: Linux Kernel-4.18-RC4 lançado em 2018-7-9 e OpenSSL-1-1-1-1-PRE8 lançado em 2018-6-20 para avaliar nossa abordagem. Avaliamos nossa abordagem a partir de duas perspectivas.
Também testamos esses casos no Apisan, uma ferramenta de detecção de usos de API higienizada por meio da verificação cruzada semântica e Clang-SA, uma ferramenta de análise estática de código aberto.
Carregamos o benchmark da API-Misuse e os resultados originais em avaliação_data.
A principal motivação do imchecker é detectar bugs de uso de API em programas do mundo real, a saber, determinar se o imchecker pode encontrar bugs anteriormente desconhecidos. Portanto, aplicamos o IMCHECKER às versões mais recentes de dois programas conhecidos de código aberto: Linux Kernel-4.18-RC4 e OpenSSL-1-1-1-1-PRE8 e pacotes no Ubuntu 16.04. As APIs alvo são selecionadas entre as mal utilizadas do estudo empírico.
Até agora, 56 bugs anteriormente desconhecidos foram encontrados e 36 foram confirmados pelos desenvolvedores.
| Projeto | Bugs (resposta de espera/confirmada/corrigida) |
|---|---|
| OpenSSL | 17 (0/5/12) |
| Linux | 30 (20/5/5) |
| DMA | 1 (0/0/1) |
| exim | 2 (0/0/2) |
| Hexchat | 2 (1/1/0) |
| httping | 1 (0/1/0) |
| IPMITOOL | 1 (0/1/0) |
| Toolas abertas | 2 (0/0/2) |
| Irssi | 2 (1/1/0) |
| mantido | 2 (0/0/2) |
| THC-IPV6 | 2 (0/0/2) |
| Freeradius-server | 2 (0/0/2) |
| Traficserver | 3 (3/0/0) |
| Tinc | 2 (0/0/2) |
| sslplit | 2 (0/0/2) |
| rdesktop | 2 (2/0/0) |
| Proxytunnel | 2 (2/0/0) |
| Total | 75 (16/29/32) |
Carregamos os detalhes em avaliação_data/new_bugs
As especificações comportamentais que descrevem as restrições de uso da API demonstraram ser úteis para os desenvolvedores utilizarem efetivamente as APIs, bem como lidar com o problema de uso escasso, garantindo a validação dos usos das APIs alvo. Por exemplo, Bodden apresenta Crysl para preencher a lacuna cognitiva entre especialistas em criptografia e desenvolvedores. No entanto, as linguagens de especificação atual são projetadas para propriedades completas do programa, como BLAST, JML ou são específicas demais para serem aplicadas à detecção genérica de API-USAGE, como o SLIC. Introduzimos um idioma leve específico do domínio para restrições de uso da API chamado IMSpec. O IMSPEC garante simultaneamente que as APIs de destino sejam validadas, mesmo com poucos usos, e guia a detecção de uso indevido. Uma instância do IMSPEC é um padrão preenchido com um conjunto de restrições para usar corretamente a API, e qualquer violação resultará em um bug da API-Assuse.
Nós carregamos as instâncias do IMSPEC na pasta IMPSEC, atualizaremos incrementalmente esta pasta para obter mais APIs. Além disso, o IMSPEC pode ser usado para outros propósitos, como gerar casos de teste, verificação e assim por diante. Além disso, fornecemos um escritor da GUI IMSPEC na Ferramentas.
Atualmente, o IMSPEC é criado pela redação manual. No entanto, garantimos que ele possa ser gerado automaticamente a partir de técnicas de mineração de especificações. Estamos tentando o nosso melhor para realizar experimentos e implementar analisadores para traduzir os resultados das ferramentas de mineração no IMSPEC, como o Apex. Mas, essas ferramentas não podem resolver todas as restrições de uso. Também gostaríamos de convidar os desenvolvedores para nos ajudar a refinar as instâncias do IMSPEC geradas de acordo com o manual do usuário, como o OpenSSL.
Um uso API correto deve satisfazer um conjunto de restrições de uso, ou seja, as violações das restrições podem resultar em bugs da API-Misuse. O IMCHECKER detecta automaticamente esses erros no código -fonte usando as especificações do IMSPEC. Para processar programas complexos e do mundo real, os mecanismos subjacentes do IMCHECKER devem ser escaláveis enquanto sacrifica a quantidade mínima de precisão. Elaboramos os detalhes do design do ImChecker, incluindo a execução simbólica subestimada com técnicas de análise estática para criar contexto de análise, metodologias para detectar bugs de uso de API no contexto de análise e um método para filtrar falsos positivos usando informações semânticas e estatísticas de uso.
Utilizamos um exemplo motivador para ilustrar o fluxo de trabalho do Imchecker. Este é um bug de uso da API no OpenSSL relatado no CVE-2015-0288. A verificação de código de erro ausente do X509_get_pubkey() resultou em um bug de desreferência do ponteiro nulo na linha-4.
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }Aqui está o fluxo de trabalho do imchecker:
O IMCHECKER pega as restrições de código -fonte e uso da API como entrada e gera relatórios de bugs com locais e razões concretas como saída. Primeiro, as restrições de uso da API são escritas em uma linguagem leve específica de domínio chamada IMSPEC; Por exemplo, "o valor de retorno de x509_get_pubkey () deve ser verificado com nulo" . Ao empregar essas especificações, a IMCHECKER valida diretamente os usos da API de destino, que alivia o problema de uso escasso e orienta o processo de detecção de bugs. Em seguida, detectamos bugs de uso da API em três fases. (1) Na fase 1, o contexto de análise é construído construindo o gráfico de fluxo de controle e criando rastreios de caminho do programa para cada API de destino definida nas especificações empregando uma execução simbólica restrita com análise de ponto, alcance e caminho. Neste exemplo, dois traços, T1 e T2, são gerados, como mostrado na caixa acima dos traços do caminho do programa. Dessa forma, o imchecker pode capturar com êxito o contexto de uso de X509_get_pubkey() , EVP_PKEY_free() e aqueles que estão no meio. (2) Na fase-2, o ImChecker emprega os traços para detectar violações das restrições como bugs em potencial. FOREXMOM, duas instâncias de uso de uso de X509_get_pubkey() são encontradas para verificações de código de erro ausentes rotuladas como bugs em potencial. (3) Na fase 3, o ImChecker melhora a precisão da detecção, alavancando várias instâncias de uso e as informações semânticas. Em seguida, o segundo uso indevido é filtrado para a verificação realizada no X509_to_X509_REQ() na linha 25.
O uso da nossa ferramenta pode ser encontrado aqui: ferramentas/readme.md
Ao investigar os relatórios de bug gerados pelo IMCHECKER, encontramos vários bugs interessantes e adquirimos experiência útil no processo de relatório de bugs com desenvolvedores de código aberto. Compartilhamos nossa experiência seguinte.
Os autores gostariam de agradecer aos desenvolvedores do Linux Kernel e OpenSSL para nos ajudar a refinar o IMSPEC e confirmar relatórios de bugs.
