semgrep-rules

"La superficie de ataque es la vulnerabilidad. Encontrar un bug allí es solo un detalle."

-- Mark Dowd

"Algunos detalles son más importantes que otros."

-- Fedor G. Pikus

Una colección de mis reglas de Semgrep para facilitar la investigación de vulnerabilidades.

Entradas del 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/

Ver también

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

Instrucciones de configuración y uso

1. Instala Semgrep.
2. Para usar estas reglas a través del registro de Semgrep, ejecuta lo siguiente desde la carpeta raíz de tu repositorio de código fuente objetivo:

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

Alternativamente, puedes clonar este repositorio de GitHub localmente y ejecutar:

# 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] Usa el modificador --no-git-ignore para escanear archivos independientemente del estado de seguimiento de git o de las reglas de .gitignore.

Para una experiencia más ágil, recomiendo guardar la salida del escaneo de Semgrep en formato SARIF y usar SARIF Explorer en 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 

Consulta también el ejemplo de salida SARIF incluido.

Compatibilidad

Probado con Semgrep CLI 1.169.0.

Reglas

C/C++

Conjunto de reglas C (y a veces C++) probado en combate.

desbordamientos de búfer

• insecure-api-gets. Uso de la función de API insegura gets.
• insecure-api-strcpy-strcat. Uso de funciones de API potencialmente inseguras strcpy, stpcpy, strcat.
• insecure-api-sprintf-vsprintf. Uso de funciones de API potencialmente inseguras sprintf y vsprintf.
• insecure-api-scanf. Uso de funciones de API potencialmente inseguras de la familia scanf.
• incorrect-use-of-strncat. Argumento de tamaño incorrecto pasado a strncat.
• use-of-source-size-in-copy. Argumento de tamaño incorrecto pasado a strncpy, , y variantes.

desbordamientos de enteros

• integer-wraparound. Posibles errores de wraparound de enteros.
• unsafe-strlen. Convertir el valor de retorno de strlen a short puede ser peligroso.
• integer-truncation. Posibles errores de truncamiento de enteros.
• signed-unsigned-conversion. Posibles errores de conversión con/sin signo.
• incorrect-unsigned-comparison. Comprobar si una variable sin signo es negativa.

cadenas de formato

• format-string-bugs. Posibles errores de cadena de formato.

gestión de memoria

• insecure-api-alloca. Uso de la función de API potencialmente insegura alloca.
• use-after-free. Posible uso después de free.
• double-free. Posible doble free.
• incorrect-use-of-free. Llamar a free sobre memoria que no está en el heap.
• unchecked-ret-malloc. Código de retorno no comprobado de malloc, calloc, realloc, etc.
• putenv-stack-var. Llamada a putenv con una variable asignada en la pila.
• ret-stack-address. Posible retorno de la dirección de una variable asignada en la pila.

inyección de comandos

• command-injection. Posible inyección de comandos del sistema operativo a través de system o popen.

condiciones de carrera

• insecure-api-access-stat. Uso de funciones de API inseguras access, stat, lstat, etc.
• insecure-api-mktemp-tmpnam-tempnam. Uso de funciones de API inseguras mktemp, tmpnam, tempnam.
• insecure-api-signal. Uso de la función de API insegura signal.

gestión de privilegios

• incorrect-order-setuid-setgid. Funciones de gestión de privilegios llamadas en el orden incorrecto.
• unchecked-ret-setuid-seteuid. Código de retorno no comprobado de setuid y seteuid.

denegación de servicio

• regex-dos. Expresión regular que puede presentar un tiempo de ejecución exponencial y provocar ReDoS.

miscelánea

• incorrect-use-of-memset. Orden incorrecto de los argumentos de memset.
• insecure-api-rand-srand. Uso de funciones de API potencialmente inseguras rand y srand.
• overlapping-source-destination. Superposición de origen y destino en funciones de copia.
• suspicious-assert. Comprobación de tamaño potencialmente inválida debido al uso de macros de aserción.
• interesting-api-calls. Llamadas a funciones de API interesantes y potencialmente inseguras.
• unchecked-ret-scanf. Código de retorno no comprobado de funciones de la familia scanf.
• insecure-api-ato. Uso de funciones de API potencialmente inseguras atoi, atol, atof.

Ruidosas

Estas reglas se consideran potencialmente demasiado ruidosas e inadecuadas para el uso general.

genérico

• bad-words. Palabras clave y comentarios que sugieren la presencia de errores.

Historial de cambios

• CHANGELOG.md

Pendientes

Tareas a corto plazo

• Procesar los issues y pull requests abiertos.
• Añadir nuevas comprobaciones a las reglas existentes y agregar nuevas reglas donde sea necesario.
• Mejorar la precisión general y reducir los falsos positivos, sin pasar por alto posibles puntos críticos en el código.
• Comprobar el rendimiento (ver test_public_repos.py).
• Benchmarking adicional con --time contra código del mundo real para detectar reglas lentas que necesiten optimización.

Tareas a largo plazo

• Añadir scripts para limpiar el pseudocódigo generado por decompiladores comunes para mejorar el análisis de Semgrep.
• Trasladar las reglas al motor Semgrep Pro, que permite el análisis entre archivos y entre funciones.
• Implementar el modo taint cuando corresponda para mejorar las reglas con análisis de flujo de datos.
• Investigar la propagación simbólica que podría ser útil para reducir algunos falsos positivos.
• Implementar un envoltorio y posprocesador de Semgrep como se describe en esta investigación.

Conjuntos de reglas específicos de dominio

• Implementar reglas de kernel dedicadas (Linux, BSD, macOS, etc.).
• Implementar reglas dedicadas de crypto y rng.
• Implementar reglas de C++ dedicadas y moverlas a otra carpeta separada de la de reglas de C.
• Crear un conjunto de reglas específico para Rust.