semgrep-rules

"La surface d'attaque est la vulnérabilité. Trouver un bug là-dedans n'est qu'un détail."

-- Mark Dowd

"Certains détails sont plus importants que d'autres."

-- Fedor G. Pikus

Une collection de mes règles Semgrep pour faciliter la recherche de vulnérabilités.

Articles de 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/

Voir aussi

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

Instructions d'installation et d'utilisation

1. Installez Semgrep.
2. Pour utiliser ces règles via le registre Semgrep, exécutez la commande suivante depuis le dossier racine de votre dépôt de code source cible :

# analyse haute priorité (gains rapides)
semgrep --severity ERROR --config "p/0xdea"

# analyse haute et moyenne priorité (recommandé)
semgrep --severity ERROR --severity WARNING --config "p/0xdea"

# analyse complète (peut inclure des résultats marginaux et plus de faux positifs)
semgrep --config "p/0xdea"

Alternativement, vous pouvez cloner ce dépôt GitHub localement et exécuter :

# analyse complète
semgrep --config semgrep-rules/rules /chemin/vers/la/source

# analyse d'une règle spécifique
semgrep --config semgrep-rules/rules/c/command-injection.yaml /chemin/vers/la/source

[!TIP] Utilisez l'option --no-git-ignore pour analyser les fichiers indépendamment du suivi git ou des règles .gitignore.

Pour une expérience plus fluide, je recommande de sauvegarder la sortie de l'analyse Semgrep au format SARIF et d'utiliser SARIF Explorer dans VS code :

semgrep --sarif --sarif-output=/chemin/vers/la/source/SEMGREP.sarif --config semgrep-rules/rules /chemin/vers/la/source
code /chemin/vers/la/source # puis ouvrez le fichier SEMGREP.sarif dans VS code avec SARIF Explorer 

Voir aussi l'exemple de sortie SARIF inclus.

Compatibilité

Testé avec Semgrep CLI 1.169.0.

Règles

C/C++

Ensemble de règles C (et parfois C++) testé en conditions réelles.

débordements de tampon

• insecure-api-gets. Utilisation de la fonction d'API non sécurisée gets.
• insecure-api-strcpy-strcat. Utilisation des fonctions d'API potentiellement non sécurisées strcpy, stpcpy, strcat.
• insecure-api-sprintf-vsprintf. Utilisation des fonctions d'API potentiellement non sécurisées sprintf et vsprintf.
• insecure-api-scanf. Utilisation des fonctions d'API potentiellement non sécurisées de la famille scanf.
• incorrect-use-of-strncat. Argument de taille incorrect passé à strncat.
• use-of-source-size-in-copy. Argument de taille incorrect passé à strncpy, memcpy, snprintf, et variantes.
• incorrect-use-of-sizeof. Utilisation accidentelle de l'opérateur sizeof sur un pointeur au lieu de sa cible.
• unterminated-string-strncpy. Absence de terminaison explicite par NUL après strncpy et stpncpy.
• off-by-one. Erreur potentielle de décalage d'un (off-by-one).
• unsafe-ret-snprintf-vsnprintf. Utilisation potentiellement dangereuse de la valeur de retour de snprintf et vsnprintf.
• unsafe-ret-strlcpy-strlcat. Utilisation potentiellement dangereuse de la valeur de retour de strlcpy et strlcat.
• pointer-subtraction. Utilisation potentielle de la soustraction de pointeurs pour déterminer la taille.
• write-into-stack-buffer. Écriture directe dans un tampon alloué sur la pile.

débordements d'entiers

• integer-wraparound. Erreurs potentielles de dépassement d'entiers par enroulement (wraparound).
• unsafe-strlen. Convertir la valeur de retour de strlen en short peut être dangereux.
• integer-truncation. Erreurs potentielles de troncature d'entiers.
• signed-unsigned-conversion. Erreurs potentielles de conversion signé/non signé.
• incorrect-unsigned-comparison. Vérifier si une variable non signée est négative.

chaînes de format

• format-string-bugs. Bogues potentiels de chaîne de format.

gestion de la mémoire

• insecure-api-alloca. Utilisation de la fonction d'API potentiellement non sécurisée alloca.
• use-after-free. Utilisation potentielle après free.
• double-free. Double free potentiel.
• incorrect-use-of-free. Appel de free sur une mémoire ne se trouvant pas dans le tas.
• unchecked-ret-malloc. Code de retour non vérifié de malloc, calloc, realloc, etc.
• putenv-stack-var. Appel à putenv avec une variable allouée sur la pile.
• ret-stack-address. Retour potentiel de l'adresse d'une variable allouée sur la pile.
• mismatched-memory-management. Routines de gestion de la mémoire C potentiellement incompatibles.
• mismatched-memory-management-cpp. Routines de gestion de la mémoire C++ potentiellement incompatibles.
• memory-address-exposure. Exposition potentielle d'adresses mémoire sous-jacentes.

injection de commandes

• command-injection. Injection de commande OS potentielle via system ou popen.

conditions de concurrence

• insecure-api-access-stat. Utilisation des fonctions d'API non sécurisées access, stat, lstat, etc.
• insecure-api-mktemp-tmpnam-tempnam. Utilisation des fonctions d'API non sécurisées mktemp, tmpnam, tempnam.
• insecure-api-signal. Utilisation de la fonction d'API non sécurisée signal.

gestion des privilèges

• incorrect-order-setuid-setgid. Fonctions de gestion des privilèges appelées dans le mauvais ordre.
• unchecked-ret-setuid-seteuid. Code de retour non vérifié de setuid et seteuid.

déni de service

• regex-dos. Expression régulière pouvant présenter un temps d'exécution exponentiel et mener à une attaque ReDoS.

divers

• incorrect-use-of-memset. Ordre incorrect des arguments de memset.
• insecure-api-rand-srand. Utilisation des fonctions d'API potentiellement non sécurisées rand et srand.
• overlapping-source-destination. Chevauchement de la source et de la destination dans les fonctions de copie.
• suspicious-assert. Vérification de taille potentiellement invalide due à l'utilisation de macros d'assertion.
• interesting-api-calls. Appels à des fonctions d'API intéressantes et potentiellement non sécurisées.
• unchecked-ret-scanf. Code de retour non vérifié des fonctions de la famille scanf.
• insecure-api-ato. Utilisation des fonctions d'API potentiellement non sécurisées atoi, atol, atof.
• high-entropy-assignment. Affectation d'une valeur à haute entropie pouvant être un secret.
• argv-envp-access. Accès à un argument de ligne de commande ou à une variable d'environnement.
• missing-default-in-switch. Absence de cas default dans une instruction switch.
• missing-break-in-switch. Absence de break ou équivalent dans une instruction switch.
• missing-return. Absence d'instruction return dans une fonction non void.
• typos. Fautes de frappe potentielles avec implications de sécurité.

Bruitées

Ces règles sont considérées comme potentiellement trop bruitées et inadaptées à une utilisation générale.

générique

• bad-words. Mots-clés et commentaires suggérant la présence de bogues.

Journal des modifications

• CHANGELOG.md

À faire

Actions à court terme

• Traiter les issues et pull requests ouvertes.
• Ajouter de nouvelles vérifications aux règles existantes et ajouter de nouvelles règles si nécessaire.
• Améliorer la précision globale et réduire les faux positifs, sans manquer les points chauds potentiels dans le code.
• Vérifier les performances (voir test_public_repos.py).
• Analyse comparative supplémentaire avec --time sur du code réel pour repérer les règles lentes nécessitant une optimisation.

Actions à long terme

• Ajouter des scripts pour nettoyer le pseudo-code généré par les décompilateurs courants pour améliorer l'analyse Semgrep.
• Porter les règles vers le moteur Semgrep Pro, qui permet une analyse inter-fichier et inter-fonction.
• Implémenter le mode taint là où cela convient pour améliorer les règles avec une analyse de flux de données.
• Étudier la propagation symbolique qui pourrait être utile pour réduire certains faux positifs.
• Implémenter un wrapper et post-processeur Semgrep comme décrit dans cette recherche.

Ensembles de règles spécifiques à un domaine

• Implémenter des règles noyau dédiées (Linux, BSD, macOS, etc.).
• Implémenter des règles crypto et rng dédiées.
• Implémenter des règles C++ dédiées et les déplacer dans un dossier séparé de celui des règles C.
• Créer un ensemble de règles spécifique pour Rust.