semgrep-rules

"A superfície de ataque é a vulnerabilidade. Encontrar um bug lá é apenas um detalhe."

-- Mark Dowd

"Alguns detalhes são mais importantes do que outros."

-- Fedor G. Pikus

Uma coleção das minhas regras Semgrep para facilitar a pesquisa de vulnerabilidades.

Postagens no blog

• https://hnsecurity.it/blog/semgrep-ruleset-for-c-c-vulnerability-research
• https://hnsecurity.it/blog/automating-binary-vulnerability-discovery-with-ghidra-and-semgrep
• https://hnsecurity.it/blog/big-update-to-my-semgrep-c-cpp-ruleset
• https://hnsecurity.it/blog/streamlining-vulnerability-research-with-the-idalib-rust-bindings-for-ida-9-2/
• https://hnsecurity.it/blog/my-semgrep-c-cpp-ruleset-is-ready-for-prime-time-again/

Veja também

• https://appsec.guide/docs/static-analysis/semgrep/
• https://semgrep.dev/docs/writing-rules/overview
• https://semgrep.dev/r

Instruções de configuração e uso

1. Instale o Semgrep.
2. Para usar essas regras por meio do registro do Semgrep, execute o seguinte a partir da pasta raiz do repositório de código-fonte de destino:

# high priority scan (quick wins)
semgrep --severity ERROR --config "p/0xdea"

# high and medium priority scan (recommended)
semgrep --severity ERROR --severity WARNING --config "p/0xdea"

# full scan (might include marginal findings and more false positives)
semgrep --config "p/0xdea"

Alternativamente, você pode clonar este repositório GitHub localmente e executar:

# full scan
semgrep --config semgrep-rules/rules /path/to/source

# specific rule scan
semgrep --config semgrep-rules/rules/c/command-injection.yaml /path/to/source

[!TIP] Especifique a opção --no-git-ignore para examinar arquivos independentemente do status de rastreamento git ou das regras de .gitignore.

Para uma experiência mais simplificada, recomendo salvar a saída da verificação do Semgrep no formato SARIF e usar o SARIF Explorer no VS code:

semgrep --sarif --sarif-output=/path/to/source/SEMGREP.sarif --config semgrep-rules/rules /path/to/source
code /path/to/source # then open the SEMGREP.sarif file in VS code with SARIF Explorer 

Veja também o exemplo de saída SARIF incluído.

Compatibilidade

Testado com Semgrep CLI 1.169.0.

Regras

C/C++

Conjunto de regras C (e às vezes C++) testado em batalha.

estouros de buffer

• insecure-api-gets. Uso da função de API insegura gets.
• insecure-api-strcpy-strcat. Uso de funções de API potencialmente inseguras strcpy, stpcpy, strcat.
• insecure-api-sprintf-vsprintf. Uso de funções de API potencialmente inseguras sprintf e vsprintf.
• insecure-api-scanf. Uso de funções de API potencialmente inseguras na família scanf.
• incorrect-use-of-strncat. Argumento de tamanho incorreto passado para strncat.
• use-of-source-size-in-copy. Argumento de tamanho incorreto passado para strncpy, , e variantes.

estouros de inteiros

• integer-wraparound. Potenciais erros de wraparound de inteiros.
• unsafe-strlen. Converter o valor de retorno de strlen para short pode ser perigoso.
• integer-truncation. Potenciais erros de truncamento de inteiros.
• signed-unsigned-conversion. Potenciais erros de conversão entre com sinal e sem sinal.
• incorrect-unsigned-comparison. Verificar se uma variável sem sinal é negativa.

strings de formato

• format-string-bugs. Potenciais bugs de string de formato.

gerenciamento de memória

• insecure-api-alloca. Uso da função de API potencialmente insegura alloca.
• use-after-free. Uso potencial após free.
• double-free. free duplo potencial.
• incorrect-use-of-free. Chamar free em memória que não está no heap.
• unchecked-ret-malloc. Código de retorno não verificado de malloc, calloc, realloc, etc.
• putenv-stack-var. Chamada a putenv com uma variável alocada na pilha.
• ret-stack-address. Retorno potencial do endereço de uma variável alocada na pilha.

injeção de comandos

• command-injection. Possível injeção de comandos do SO via system ou popen.

condições de corrida

• insecure-api-access-stat. Uso de funções de API inseguras access, stat, lstat, etc.
• insecure-api-mktemp-tmpnam-tempnam. Uso de funções de API inseguras mktemp, tmpnam, tempnam.
• insecure-api-signal. Uso da função de API insegura signal.

gerenciamento de privilégios

• incorrect-order-setuid-setgid. Funções de gerenciamento de privilégios chamadas na ordem errada.
• unchecked-ret-setuid-seteuid. Código de retorno não verificado de setuid e seteuid.

negação de serviço

• regex-dos. Expressão regular que pode apresentar tempo de execução exponencial e levar a ReDoS.

diversos

• incorrect-use-of-memset. Ordem errada dos argumentos para memset.
• insecure-api-rand-srand. Uso de funções de API potencialmente inseguras rand e srand.
• overlapping-source-destination. Sobreposição de origem e destino em funções de cópia.
• suspicious-assert. Verificação de tamanho potencialmente inválida devido ao uso de macros de asserção.
• interesting-api-calls. Chamadas a funções de API interessantes e potencialmente inseguras.
• unchecked-ret-scanf. Código de retorno não verificado de funções da família scanf.
• insecure-api-ato. Uso de funções de API potencialmente inseguras atoi, atol, atof.

Ruidosas

Essas regras são consideradas potencialmente ruidosas demais e inadequadas para uso geral.

genéricas

• bad-words. Palavras-chave e comentários que sugerem a presença de bugs.

Registro de alterações

• CHANGELOG.md

Tarefas pendentes

Itens de ação de curto prazo

• Processar issues abertas e pull requests abertos.
• Adicionar novas verificações às regras existentes e adicionar novas regras onde necessário.
• Melhorar a precisão geral e reduzir falsos positivos, sem perder possíveis pontos críticos no código.
• Verificar o desempenho (veja test_public_repos.py).
• Benchmarking adicional com --time contra código do mundo real para identificar regras lentas que precisam de otimização.

Itens de ação de longo prazo

• Adicionar scripts para limpar o pseudocódigo gerado por decompiladores comuns para melhorar o parsing do Semgrep.
• Portar as regras para o mecanismo Semgrep Pro, que permite análise entre arquivos e entre funções.
• Implementar o modo taint onde for adequado para melhorar as regras com análise de fluxo de dados.
• Investigar a propagação simbólica que pode ser útil para reduzir alguns falsos positivos.
• Implementar um wrapper e pós-processador do Semgrep conforme descrito em esta pesquisa.

Conjuntos de regras específicos de domínio

• Implementar regras de kernel dedicadas (Linux, BSD, macOS, etc.).
• Implementar regras dedicadas de crypto e rng.
• Implementar regras C++ dedicadas e movê-las para outra pasta separada daquela das regras C.
• Criar um conjunto de regras específico para Rust.