semgrep-rules

「攻撃対象領域こそが脆弱性だ。そこでバグを見つけるのは単なる詳細にすぎない。」

-- Mark Dowd

「ある詳細は、他の詳細よりも重要である。」

-- Fedor G. Pikus

脆弱性調査を容易にするための私のSemgrepルール集です。

ブログ記事

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

関連情報

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

セットアップと使用方法

1. Semgrepをインストールします。
2. Semgrepレジストリ経由でこれらのルールを使用するには、対象のソースコードリポジトリのルートフォルダから次のコマンドを実行します：

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

あるいは、このGitHubリポジトリをローカルにクローンして、次のように実行することもできます：

# 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] --no-git-ignore スイッチを指定すると、Gitの追跡ステータスや .gitignore ルールに関係なくファイルをスキャンできます。

よりスムーズに進めるには、Semgrepスキャン出力をSARIF形式で保存し、VS codeでSARIF Explorerを使用することをお勧めします：

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 

同梱のSARIF出力の例も参照してください。

互換性

Semgrep CLI 1.169.0でテスト済み。

ルール

C/C++

実戦で検証済みのC（場合によってはC++）ルールセット。

バッファオーバーフロー

• insecure-api-gets。安全でないAPI関数getsの使用。
• insecure-api-strcpy-strcat。潜在的に安全でないAPI関数strcpy、stpcpy、strcatの使用。
• insecure-api-sprintf-vsprintf。潜在的に安全でないAPI関数sprintfおよびvsprintfの使用。
• insecure-api-scanf。scanfファミリーの潜在的に安全でないAPI関数の使用。
• incorrect-use-of-strncat。strncatに渡すサイズ引数の誤り。
• use-of-source-size-in-copy。strncpy、memcpy、およびその亜種に渡すサイズ引数の誤り。

整数オーバーフロー

• integer-wraparound。潜在的な整数ラップアラウンドエラー。
• unsafe-strlen。strlenの戻り値をshortにキャストすると危険な場合がある。
• integer-truncation。潜在的な整数切り詰めエラー。
• signed-unsigned-conversion。潜在的な符号付き/符号なし変換エラー。
• incorrect-unsigned-comparison。符号なし変数が負かどうかをチェック。

フォーマット文字列

• format-string-bugs。潜在的なフォーマット文字列バグ。

メモリ管理

• insecure-api-alloca。潜在的に安全でないAPI関数allocaの使用。
• use-after-free。free後の潜在的な使用。
• double-free。潜在的な二重free。
• incorrect-use-of-free。ヒープ上にないメモリに対してfreeを呼び出している。
• unchecked-ret-malloc。malloc、calloc、reallocなどの戻り値をチェックしていない。
• putenv-stack-var。スタック割り当て変数を使ってputenvを呼び出している。
• ret-stack-address。スタック割り当て変数のアドレスを返す可能性。
• 。潜在的に不整合なCメモリ管理ルーチン。

コマンドインジェクション

• command-injection。systemまたはpopenによる潜在的なOSコマンドインジェクション。

レースコンディション

• insecure-api-access-stat。安全でないAPI関数access、stat、lstatなどの使用。
• insecure-api-mktemp-tmpnam-tempnam。安全でないAPI関数mktemp、tmpnam、tempnamの使用。
• insecure-api-signal。安全でないAPI関数signalの使用。

権限管理

• incorrect-order-setuid-setgid。権限管理関数が誤った順序で呼び出されている。
• unchecked-ret-setuid-seteuid。setuidおよびseteuidの戻り値をチェックしていない。

サービス拒否

• regex-dos。指数関数的な実行時間を示し、ReDoSを引き起こす可能性のある正規表現。

その他

• incorrect-use-of-memset。memsetへの引数の順序の誤り。
• insecure-api-rand-srand。潜在的に安全でないAPI関数randおよびsrandの使用。
• overlapping-source-destination。コピー関数におけるコピー元とコピー先の重なり。
• suspicious-assert。アサーションマクロの使用による潜在的に無効なサイズチェック。
• interesting-api-calls。注目すべき、潜在的に安全でないAPI関数の呼び出し。
• unchecked-ret-scanf。scanfファミリーの関数の戻り値をチェックしていない。
• insecure-api-ato。潜在的に安全でないAPI関数atoi、atol、atofの使用。
• high-entropy-assignment。秘密情報である可能性のある高エントロピー値の代入。

ノイジー

これらのルールはノイズが多すぎる可能性があり、一般的な使用には適さないと見なされています。

汎用

• bad-words。バグの存在を示唆するキーワードとコメント。

変更履歴

• CHANGELOG.md

TODO

短期的なアクション項目

• 未処理のissuesとpull requestsを処理する。
• 既存のルールに新しいチェックを追加し、必要に応じて新しいルールを追加する。
• コード内の潜在的なホットスポットを見逃さずに、全体的な正確性を向上させ、誤検知を減らす。
• パフォーマンスを確認する（test_public_repos.pyを参照）。
• 実世界のコードに対する追加の--timeベンチマークを実施し、最適化が必要な低速ルールを見つける。

長期的なアクション項目

• Semgrepの解析を改善するため、一般的な逆コンパイラが生成した擬似コードをクリーンアップするスクリプトを追加する。
• ルールをSemgrep Proエンジンに移植する。これにより、ファイル間および関数間の分析が可能になる。
• 適切な箇所でtaint modeを実装し、データフロー分析でルールを改善する。
• 一部の誤検知を減らすのに役立つ可能性があるsymbolic propagationを調査する。
• この研究で説明されているようなSemgrepのラッパーと後処理ツールを実装する。

ドメイン固有のルールセット

• 専用のカーネルルール（Linux、BSD、macOSなど）を実装する。
• 専用のcryptoおよびrngルールを実装する。
• 専用のC++ルールを実装し、Cルール用のフォルダとは別のフォルダに移動する。
• Rust用の専用ルールセットを作成する。