semgrep-rules

„Die Angriffsfläche ist die Schwachstelle. Einen Bug dort zu finden, ist nur ein Detail.“

– Mark Dowd

„Manche Details sind wichtiger als andere.“

– Fedor G. Pikus

Eine Sammlung meiner Semgrep-Regeln, um Schwachstellenforschung zu erleichtern.

Blogbeiträge

• 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/

Siehe auch

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

Einrichtungs- und Verwendungshinweise

1. Installieren Sie Semgrep.
2. Um diese Regeln über die Semgrep-Registry zu verwenden, führen Sie Folgendes aus dem Stammverzeichnis Ihres Zielquellcode-Repositorys aus:

# Hochprioritäts-Scan (schnelle Erfolge)
semgrep --severity ERROR --config "p/0xdea"

# Hoch- und mittelprioritäts-Scan (empfohlen)
semgrep --severity ERROR --severity WARNING --config "p/0xdea"

# Vollständiger Scan (kann Randbefunde und mehr Fehlalarme enthalten)
semgrep --config "p/0xdea"

Alternativ können Sie dieses GitHub-Repository lokal klonen und ausführen:

# Vollständiger Scan
semgrep --config semgrep-rules/rules /path/to/source

# Scan einer bestimmten Regel
semgrep --config semgrep-rules/rules/c/command-injection.yaml /path/to/source

[!TIP] Geben Sie den Schalter --no-git-ignore an, um Dateien unabhängig vom Git-Tracking-Status oder .gitignore-Regeln zu scannen.

Für eine bessere und optimierte Erfahrung empfehle ich, die Semgrep-Scanausgabe im SARIF-Format zu speichern und SARIF Explorer in VS Code zu verwenden:

semgrep --sarif --sarif-output=/path/to/source/SEMGREP.sarif --config semgrep-rules/rules /path/to/source
code /path/to/source # dann die SEMGREP.sarif-Datei in VS Code mit SARIF Explorer öffnen

Siehe auch das beigefügte SARIF-Ausgabe-Beispiel.

Kompatibilität

Getestet mit Semgrep CLI 1.169.0.

Regeln

C/C++

Kampferprobtes C- (und manchmal C++) Regelset.

Pufferüberläufe

• insecure-api-gets. Verwendung der unsicheren API-Funktion gets.
• insecure-api-strcpy-strcat. Verwendung potenziell unsicherer API-Funktionen strcpy, stpcpy, strcat.
• insecure-api-sprintf-vsprintf. Verwendung potenziell unsicherer API-Funktionen sprintf und vsprintf.
• insecure-api-scanf. Verwendung potenziell unsicherer API-Funktionen der scanf-Familie.
• incorrect-use-of-strncat. Falsches Größenargument an strncat übergeben.
• use-of-source-size-in-copy. Falsches Größenargument an strncpy, , und Varianten übergeben.

Integer-Überläufe

• integer-wraparound. Potenzielle Integer-Überlauffehler.
• unsafe-strlen. Das Casten des Rückgabewerts von strlen auf short kann gefährlich sein.
• integer-truncation. Potenzielle Integer-Abschneidefehler.
• signed-unsigned-conversion. Potenzielle Fehler bei der Konvertierung von signed/unsigned.
• incorrect-unsigned-comparison. Überprüfung, ob eine unsigned-Variable negativ ist.

Formatstrings

• format-string-bugs. Potenzielle Formatstring-Fehler.

Speicherverwaltung

• insecure-api-alloca. Verwendung der potenziell unsicheren API-Funktion alloca.
• use-after-free. Potenzielle Nutzung nach free.
• double-free. Potenzielles doppeltes free.
• incorrect-use-of-free. Aufruf von free auf Speicher, der nicht im Heap liegt.
• unchecked-ret-malloc. Ungeprüfter Rückgabecode von malloc, calloc, realloc usw.
• putenv-stack-var. Aufruf von putenv mit einer stack-allozierten Variablen.
• . Potenzielle Rückgabe der Adresse einer stack-allozierten Variablen.

Befehlseinschleusung

• command-injection. Potenzielle OS-Befehlseinschleusung via system oder popen.

Wettlaufsituationen

• insecure-api-access-stat. Verwendung unsicherer API-Funktionen access, stat, lstat usw.
• insecure-api-mktemp-tmpnam-tempnam. Verwendung unsicherer API-Funktionen mktemp, tmpnam, tempnam.
• insecure-api-signal. Verwendung der unsicheren API-Funktion signal.

Berechtigungsverwaltung

• incorrect-order-setuid-setgid. Berechtigungsverwaltungsfunktionen in falscher Reihenfolge aufgerufen.
• unchecked-ret-setuid-seteuid. Ungeprüfter Rückgabecode von setuid und seteuid.

Denial of Service

• regex-dos. Regulärer Ausdruck, der exponentielle Laufzeit aufweisen und zu ReDoS führen kann.

Verschiedenes

• incorrect-use-of-memset. Falsche Argumentreihenfolge bei memset.
• insecure-api-rand-srand. Verwendung potenziell unsicherer API-Funktionen rand und srand.
• overlapping-source-destination. Quelle und Ziel überschneiden sich in Kopierfunktionen.
• suspicious-assert. Potenziell ungültige Größenprüfung aufgrund der Verwendung von Assertions-Makros.
• interesting-api-calls. Aufrufe interessanter und potenziell unsicherer API-Funktionen.
• unchecked-ret-scanf. Ungeprüfter Rückgabecode von Funktionen der scanf-Familie.
• insecure-api-ato. Verwendung potenziell unsicherer API-Funktionen atoi, atol, atof.

Laut (Noisy)

Diese Regeln gelten als potenziell zu laut und für den allgemeinen Gebrauch ungeeignet.

Generisch

• bad-words. Schlüsselwörter und Kommentare, die auf das Vorhandensein von Fehlern hindeuten.

Changelog

• CHANGELOG.md

TODO

Kurzfristige Aufgaben

• Offene Issues und Pull Requests bearbeiten.
• Neue Prüfungen zu den bestehenden Regeln hinzufügen und bei Bedarf neue Regeln hinzufügen.
• Gesamtgenauigkeit verbessern und Fehlalarme reduzieren, ohne potenzielle Hotspots im Code zu übersehen.
• Leistung überprüfen (siehe test_public_repos.py).
• Zusätzliches --time-Benchmarking gegen reale Codebasen, um langsame Regeln zu identifizieren, die optimiert werden müssen.

Langfristige Aufgaben

• Skripte hinzufügen, um Pseudocode von gängigen Decompilern zu bereinigen, um das Semgrep-Parsing zu verbessern.
• Regeln auf die Semgrep Pro Engine portieren, die dateiübergreifende und funktionsübergreifende Analyse ermöglicht.
• Taint-Modus implementieren, wo geeignet, um Regeln mit Datenflussanalyse zu verbessern.
• Symbolische Propagation untersuchen, die nützlich sein könnte, um einige Fehlalarme zu reduzieren.
• Einen Semgrep-Wrapper und Postprozessor implementieren, wie in dieser Forschungsarbeit beschrieben.

Domänenspezifische Regelsets

• Dedizierte Kernel-Regeln implementieren (Linux, BSD, macOS usw.).
• Dedizierte Krypto- und RNG-Regeln implementieren.
• Dedizierte C++-Regeln implementieren und in einen eigenen Ordner verschieben, getrennt von den C-Regeln.
• Ein spezifisches Regelset für Rust erstellen.