semgrep-rules

"The attack surface is the vulnerability. Finding a bug there is just a detail."

-- Mark Dowd

"Some details are more important than others."

-- Fedor G. Pikus

Una raccolta delle mie regole Semgrep per facilitare la ricerca di vulnerabilità.

Articoli del 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/

Vedi anche

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

Istruzioni di configurazione e utilizzo

1. Installa Semgrep.
2. Per usare queste regole tramite il registro Semgrep, esegui quanto segue dalla cartella principale del repository del codice sorgente di destinazione:

# 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"

In alternativa, puoi clonare questo repository GitHub in locale ed eseguire:

# 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] Specifica l'opzione --no-git-ignore per analizzare i file indipendentemente dallo stato di tracciamento git o dalle regole .gitignore.

Per un'esperienza più fluida, consiglio di salvare l'output dell'analisi Semgrep in formato SARIF e di usare SARIF Explorer in 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 

Vedi anche l'esempio di output SARIF incluso.

Compatibilità

Testato con Semgrep CLI 1.169.0.

Regole

C/C++

Ruleset C (e talvolta C++) collaudato sul campo.

buffer overflow

• insecure-api-gets. Uso della funzione API insicura gets.
• insecure-api-strcpy-strcat. Uso di funzioni API potenzialmente insicure strcpy, stpcpy, strcat.
• insecure-api-sprintf-vsprintf. Uso di funzioni API potenzialmente insicure sprintf e vsprintf.
• insecure-api-scanf. Uso di funzioni API potenzialmente insicure della famiglia scanf.
• incorrect-use-of-strncat. Argomento di dimensione errato passato a strncat.
• use-of-source-size-in-copy. Argomento di dimensione errato passato a strncpy, , e varianti.

integer overflow

• integer-wraparound. Potenziali errori di wraparound degli interi.
• unsafe-strlen. La conversione del valore di ritorno di strlen in short potrebbe essere pericolosa.
• integer-truncation. Potenziali errori di troncamento degli interi.
• signed-unsigned-conversion. Potenziali errori di conversione signed/unsigned.
• incorrect-unsigned-comparison. Controllo se una variabile unsigned è negativa.

format string

• format-string-bugs. Potenziali bug di format string.

gestione della memoria

• insecure-api-alloca. Uso della funzione API potenzialmente insicura alloca.
• use-after-free. Potenziale uso dopo free.
• double-free. Potenziale doppia chiamata a free.
• incorrect-use-of-free. Chiamata a free su memoria non heap.
• unchecked-ret-malloc. Codice di ritorno non controllato di malloc, calloc, realloc, ecc.
• putenv-stack-var. Chiamata a putenv con una variabile allocata sullo stack.
• ret-stack-address. Potenziale ritorno dell'indirizzo di una variabile allocata sullo stack.

iniezione di comandi

• command-injection. Potenziale iniezione di comandi del sistema operativo tramite system o popen.

race condition

• insecure-api-access-stat. Uso di funzioni API insicure access, stat, lstat, ecc.
• insecure-api-mktemp-tmpnam-tempnam. Uso di funzioni API insicure mktemp, tmpnam, tempnam.
• insecure-api-signal. Uso della funzione API insicura signal.

gestione dei privilegi

• incorrect-order-setuid-setgid. Funzioni di gestione dei privilegi chiamate nell'ordine sbagliato.
• unchecked-ret-setuid-seteuid. Codice di ritorno non controllato di setuid e seteuid.

denial of service

• regex-dos. Espressione regolare che può avere un tempo di esecuzione esponenziale e portare a ReDoS.

varie

• incorrect-use-of-memset. Ordine sbagliato degli argomenti di memset.
• insecure-api-rand-srand. Uso di funzioni API potenzialmente insicure rand e srand.
• overlapping-source-destination. Sovrapposizione di sorgente e destinazione nelle funzioni di copia.
• suspicious-assert. Controllo di dimensione potenzialmente non valido a causa dell'uso di macro di asserzione.
• interesting-api-calls. Chiamate a funzioni API interessanti e potenzialmente insicure.
• unchecked-ret-scanf. Codice di ritorno non controllato delle funzioni della famiglia scanf.
• insecure-api-ato. Uso di funzioni API potenzialmente insicure atoi, atol, atof.

Rumorose

Queste regole sono considerate potenzialmente troppo rumorose e inadatte all'uso generale.

generico

• bad-words. Parole chiave e commenti che suggeriscono la presenza di bug.

Changelog

• CHANGELOG.md

TODO

Attività a breve termine

• Gestire le issue aperte e le pull request aperte.
• Aggiungere nuovi controlli alle regole esistenti e aggiungere nuove regole dove necessario.
• Migliorare l'accuratezza complessiva e ridurre i falsi positivi, senza perdere potenziali hot spot nel codice.
• Controllare le prestazioni (vedi test_public_repos.py).
• Eseguire ulteriori benchmark --time su codice reale per individuare le regole lente che necessitano di ottimizzazione.

Attività a lungo termine

• Aggiungere script per ripulire il pseudocodice generato dai decompilatori comuni per migliorare il parsing di Semgrep.
• Portare le regole al motore Semgrep Pro, che consente l'analisi inter-file e inter-funzione.
• Implementare la modalità taint dove opportuno per migliorare le regole con l'analisi del flusso di dati.
• Studiare la propagazione simbolica che potrebbe essere utile per ridurre alcuni falsi positivi.
• Implementare un wrapper e post-processore Semgrep come descritto in questa ricerca.

Ruleset specifici per dominio

• Implementare regole kernel dedicate (Linux, BSD, macOS, ecc.).
• Implementare regole dedicate per crypto e rng.
• Implementare regole C++ dedicate e spostarle in un'altra cartella separata da quella per le regole C.
• Creare un ruleset specifico per Rust.