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

A collection of my Semgrep rules to facilitate vulnerability research.

Blog posts

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

See also

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

Setup and usage instructions

1. Install Semgrep.
2. To use these rules via the Semgrep registry, run the following from the root folder of your target source code repository:

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

Alternatively, you can clone this GitHub repository locally and run:

# 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

For a better streamlined experience, I recommend saving the Semgrep scan output in SARIF format and using 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 

See also the included SARIF output example.

Compatibility

Tested with Semgrep CLI 1.165.0.

Rules

C/C++

Battle tested C (and sometimes C++) ruleset.

buffer overflows

• insecure-api-gets. Use of the insecure API function gets.
• insecure-api-strcpy-strcat. Use of potentially insecure API functions strcpy, stpcpy, strcat.
• insecure-api-sprintf-vsprintf. Use of potentially insecure API functions sprintf and vsprintf.
• insecure-api-scanf. Use of potentially insecure API functions in the scanf family.
• incorrect-use-of-strncat. Wrong size argument passed to strncat.
• use-of-source-size-in-copy. Wrong size argument passed to strncpy, memcpy, snprintf, and variants.
• incorrect-use-of-sizeof. Accidental use of the sizeof operator on a pointer instead of its target.
• unterminated-string-strncpy. Lack of explicit NUL-termination after strncpy and stpncpy.
• off-by-one. Potential off-by-one error.
• unsafe-ret-snprintf-vsnprintf. Potentially unsafe use of the return value of snprintf and vsnprintf.
• unsafe-ret-strlcpy-strlcat. Potentially unsafe use of the return value of strlcpy and strlcat.
• pointer-subtraction. Potential use of pointer subtraction to determine size.
• write-into-stack-buffer. Direct write into buffer allocated on the stack.

integer overflows

• integer-wraparound. Potential integer wraparound errors.
• unsafe-strlen. Casting the return value of strlen to short might be dangerous.
• integer-truncation. Potential integer truncation errors.
• signed-unsigned-conversion. Potential signed/unsigned conversion errors.
• incorrect-unsigned-comparison. Checking if an unsigned variable is negative.

format strings

• format-string-bugs. Potential format string bugs.

memory management

• insecure-api-alloca. Use of the potentially insecure API function alloca.
• use-after-free. Potential use after free.
• double-free. Potential double free.
• incorrect-use-of-free. Calling free on memory not in the heap.
• unchecked-ret-malloc. Unchecked return code of malloc, calloc, realloc, etc.
• putenv-stack-var. Call to putenv with a stack-allocated variable.
• ret-stack-address. Potential return of the address of a stack-allocated variable.
• mismatched-memory-management. Potentially mismatched C memory management routines.
• mismatched-memory-management-cpp. Potentially mismatched C++ memory management routines.
• memory-address-exposure. Potential exposure of underlying memory addresses.

command injection

• command-injection. Potential OS command injection via system or popen.

race conditions

• insecure-api-access-stat. Use of insecure API functions access, stat, lstat, etc.
• insecure-api-mktemp-tmpnam-tempnam. Use of insecure API functions mktemp, tmpnam, tempnam.
• insecure-api-signal. Use of insecure API function signal.

privilege management

• incorrect-order-setuid-setgid. Privilege management functions called in the wrong order.
• unchecked-ret-setuid-seteuid. Unchecked return code of setuid and seteuid.

denial of service

• regex-dos. Regular expression that may exhibit exponential runtime and lead to ReDoS.

miscellaneous

• incorrect-use-of-memset. Wrong order of arguments to memset.
• insecure-api-rand-srand. Use of potentially insecure API functions rand and srand.
• overlapping-source-destination. Source and destination overlap in copy functions.
• suspicious-assert. Potentially invalid size check due to use of assertion macros.
• interesting-api-calls. Calls to interesting and potentially insecure API functions.
• unchecked-ret-scanf. Unchecked return code of functions in the scanf family.
• insecure-api-ato. Use of potentially insecure API functions atoi, atol, atof.
• high-entropy-assignment. Assignment of a high-entropy value that might be a secret.
• argv-envp-access. Command-line argument or environment variable access.
• missing-default-in-switch. Missing default case in a switch statement.
• missing-break-in-switch. Missing break or equivalent in a switch statement.
• missing-return. Missing return statement in non-void function.
• typos. Potential typos with security implications.

Noisy

These rules are considered potentially too noisy and unsuitable for general use.

Generic

• bad-words. Keywords and comments that suggest the presence of bugs.

Changelog

• CHANGELOG.md

TODO

Short-term action items

• Process open issues and pull requests.
• Add new checks to the existing rules and add new rules where needed.
• Improve overall accuracy and reduce false positives, without missing potential hot spots in code.
• Check performance (see test_public_repos.py).
• Additional --time benchmarking against real-world code to spot slow rules in need of optimization.

Long-term action items

• Add scripts to clean up pseudocode generated by common decompilers to improve Semgrep parsing.
• Port the rules to the Semgrep Pro engine, which allows for inter-file and inter-function analysis.
• Implement taint mode where suitable to improve rules with dataflow analysis.
• Investigate symbolic propagation that might be useful to reduce some false positives.
• Implement a Semgrep wrapper and post-processor as described in this research.

Domain-specific rulesets

• Implement dedicated kernel rules (Linux, BSD, macOS, etc.).
• Implement dedicated crypto and rng rules.
• Implement dedicated C++ rules and move them in another folder separated from the one for C rules.
• Create a specific ruleset for Rust.