semgrep-rules

«Поверхность атаки — это уязвимость. Найти там баг — всего лишь деталь.»

— Марк Дауд

«Некоторые детали важнее других.»

— Федор Г. Пикус

Коллекция моих правил 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, выполните следующие команды из корневой папки репозитория исходного кода цели:

# сканирование с высоким приоритетом (быстрые победы)
semgrep --severity ERROR --config "p/0xdea"

# сканирование с высоким и средним приоритетом (рекомендуется)
semgrep --severity ERROR --severity WARNING --config "p/0xdea"

# полное сканирование (может включать пограничные находки и больше ложных срабатываний)
semgrep --config "p/0xdea"

В качестве альтернативы вы можете клонировать этот репозиторий GitHub локально и выполнить:

# полное сканирование
semgrep --config semgrep-rules/rules /путь/к/исходнику

# сканирование по конкретному правилу
semgrep --config semgrep-rules/rules/c/command-injection.yaml /путь/к/исходнику

[!TIP] Укажите флаг --no-git-ignore, чтобы сканировать файлы независимо от статуса отслеживания git или правил .gitignore.

Для более удобной работы я рекомендую сохранять вывод сканирования Semgrep в формате SARIF и использовать SARIF Explorer в VS Code:

semgrep --sarif --sarif-output=/путь/к/исходнику/SEMGREP.sarif --config semgrep-rules/rules /путь/к/исходнику
code /путь/к/исходнику # затем откройте файл SEMGREP.sarif в VS Code с помощью 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. Использование потенциально небезопасных функций API семейства scanf.
• incorrect-use-of-strncat. Неправильный аргумент размера, переданный в strncat.
• use-of-source-size-in-copy. Неправильный аргумент размера, переданный в , , и их варианты.

целочисленные переполнения

• 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. Потенциальное возвращение адреса переменной, размещённой на стеке.

внедрение команд

• command-injection. Потенциальное внедрение команд ОС через system или popen.

состояния гонки

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

Шумные

Эти правила считаются потенциально слишком шумными и непригодными для общего использования.

общие

• bad-words. Ключевые слова и комментарии, указывающие на наличие багов.

Журнал изменений

• CHANGELOG.md

Планы

Краткосрочные задачи

• Обработать открытые issues и pull requests.
• Добавить новые проверки в существующие правила и добавить новые правила там, где это необходимо.
• Улучшить общую точность и уменьшить количество ложных срабатываний, не упуская потенциальных горячих точек в коде.
• Проверить производительность (см. test_public_repos.py).
• Дополнительное бенчмаркинг с --time на реальном коде для выявления медленных правил, нуждающихся в оптимизации.

Долгосрочные задачи

• Добавить скрипты для очистки псевдокода, созданного распространёнными декомпиляторами, для улучшения парсинга Semgrep.
• Перенести правила на движок Semgrep Pro, который позволяет проводить межфайловый и межфункциональный анализ.
• Внедрить режим taint там, где это уместно, для улучшения правил с помощью анализа потока данных.
• Изучить символическое распространение, которое может быть полезно для уменьшения некоторых ложных срабатываний.
• Реализовать обёртку и постпроцессор Semgrep, как описано в этом исследовании.

Предметно-ориентированные наборы правил

• Реализовать выделенные правила для ядра (Linux, BSD, macOS и т.д.).
• Реализовать выделенные правила для криптографии и генераторов случайных чисел.
• Реализовать выделенные правила для C++ и переместить их в отдельную папку, отдельную от правил для C.
• Создать отдельный набор правил для Rust.