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://semgrep.dev/r

Setup and usage instructions

1. Install Semgrep.
2. Clone this GitHub repo.
3. To use these rules, run:

# high priority scan (quick wins)
semgrep --severity ERROR --config semgrep-rules/rules /path/to/source
# high and medium priority scan (recommended)
semgrep --severity ERROR --severity WARNING --config semgrep-rules/rules /path/to/source
# full scan (might include marginal findings and more false positives)
semgrep --config semgrep-rules/rules /path/to/source

For a better streamlined experience, I recommend saving 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.142.0

TODO

• Additional --time benchmarking against real-world code to spot slow rules in need of optimization.
• Improve overall accuracy and reduce false positives, without missing potential hot spots in code.
• Add new checks in the existing rules and add new rules where needed.
• Implement dedicated kernel rules (Linux, BSD, macOS, etc.).
• 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.

Rules

C/C++

buffer overflows

• insecure-api-gets. Use of the insecure API function gets().
• insecure-api-strcpy-stpcpy-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-etc. Use of potentially insecure API functions in the scanf() family.
• incorrect-use-of-strncat. Wrong size argument passed to strncat().
• incorrect-use-of-strncpy-stpncpy-strlcpy. Wrong size argument passed to strncpy(), stpncpy(), strlcpy().
• incorrect-use-of-sizeof. Accidental use of the sizeof() operator on a pointer instead of its target.
• unterminated-string-strncpy-stpncpy. Lack of explicit NUL-termination after strncpy() and stpncpy().
• off-by-one. Potential off-by-one error.
• pointer-subtraction. Potential use of pointer subtraction to determine size.
• 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().
• write-into-stack-buffer. Direct write into buffer allocated on the stack.

integer overflows

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

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-calloc-realloc. Unchecked return code of malloc(), calloc(), realloc().
• ret-stack-address. Potential return of the address of a stack-allocated variable.
• putenv-stack-var. Call to putenv() with a stack-allocated variable.
• memory-address-exposure. Potential exposure of underlying memory addresses.
• mismatched-memory-management. Potentially mismatched C memory management routines.
• mismatched-memory-management-cpp. Potentially mismatched C++ memory management routines.

command injection

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

race conditions

• insecure-api-access-stat-lstat. Use of insecure API functions access(), stat(), lstat().
• 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-etc. 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().
• incorrect-use-of-sprintf-snprintf. Source and destination overlap in sprintf() and snprintf().
• 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-etc. Unchecked return code of functions in the scanf() family.
• insecure-api-atoi-atol-atof. 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.

Generic

miscellaneous

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