Кратко и по делу — по каждой уязвимости: что это, как возникает, какие меры защиты дают языки/компиляторы, и какие инструменты использовать в разработке и CI.
Buffer overflow (переполнение буфера)
- Что: запись за пределы выделенного буфера (строковые/массивные буферы) — приводит к повреждению соседних данных/возвратного адреса и удалённому выполнению кода.
- Причины: отсутствие проверки границ в ручных операциях (C/C++: strcpy, memcpy с неверными размерами).
- Как предотвращают языки/рантаймы:
- Высокоуровневые языки (Rust, Go, Java, C#, Swift) — встроенные проверки границ или безопасные коллекции; в Rust — система владения и проверка индексов в стандартной библиотеке.
- Использование безопасных API в C/C++ (std::vector::at, strlcpy, bounds-checked wrappers).
- Как помогают компиляторы/ОС:
- Stack canaries/stack guards (пример: -fstack-protector).
- DEP/NX (no-execute) и ASLR (рандомизация адресного пространства).
- Control Flow Integrity (CFI), PIE (Position Independent Executables).
- Runtime-санитайзеры: AddressSanitizer (ASan) для обнаружения heap/stack/global OOB.
- Инструменты:
- Динамические: AddressSanitizer (clang/gcc, флаг $-fsanitize=address$), Valgrind (memcheck), Electric Fence (редко).
- Статические: Clang Static Analyzer, Coverity, PVS-Studio, CodeQL (для PR-сканирования).
- Фаззеры: libFuzzer, AFL, honggfuzz (находят OOB через крахи).
Integer overflow (переполнение целого)
- Что: арифметическая операция превышает вместимость типа; в C/C++ переполнение знаковых целых — неопределённое поведение (UB), что позволяет атаки; беззнаковые чаще всего просто оборачиваются.
- Причины: неверные проверки математики размеров/индексов, умножение/сложение перед выделением памяти.
- Как предотвращают языки/рантаймы:
- Высокоуровневые языки обычно либо делают проверки, либо используют больший тип/BigInt; в Rust есть методы с явной проверкой (checked_add, overflowing_*).
- Языки с управляемой арифметикой (Java) имеют defined wrap/checked опции или библиотеки для безопасности.
- Как помогают компиляторы/инструменты:
- UndefinedBehaviorSanitizer (UBSan) с опцией для целочисленных переполнений ($-fsanitize=undefined$ / конкретные подфлаги).
- Флаги компилятора для ловли/трэпа при переполнении (например, $-ftrapv$ в gcc — вызывает сигнал при переполнении).
- Анализ статический: ищут потенциальные переполнения размеров перед аллокацией.
- Инструменты:
- UBSan ($-fsanitize=undefined$), static analyzers (Clang Static Analyzer, Coverity), фреймворки для проверки арифметики в код-ревью (CodeQL).
- Фаззинг помогает находить цепочки входных данных, приводящие к переполнению (libFuzzer/AFL).
Use-after-free (UAF)
- Что: доступ (чтение/запись/вызов) к памяти после её освобождения — может привести к краху или исполнению контролируемых данных.
- Причины: висячие указатели, двойное free, неверная семантика владения в многопоточных сценариях.
- Как предотвращают языки/рантаймы:
- Языки с автоматическим управлением памятью (Java, C#, Go) и сборкой мусора сильно снижают вероятность UAF.
- Rust — система владения/заимствования не позволяет использовать ресурсы после освобождения (боррoу-чекер).
- В C++ — умные указатели (unique_ptr, shared_ptr) и RAII уменьшают риск.
- Как помогают компиляторы/инструменты:
- ASan обнаруживает UAF (poison/unpoison области).
- Heap debuggers и специализированные allocator’ы (e.g., jemalloc с debug-опциями) помогают заметить двойной free/UAF.
- Инструменты:
- AddressSanitizer ($-fsanitize=address$) — хороший и быстрый детектор UAF.
- Valgrind/memcheck — детектирует многие UAF но медленнее.
- ThreadSanitizer (TSan) помогает при UAF, вызванных гонками; инструменты анализа владения (Clang Static Analyzer).
- Sanitizer в CI/тестах: запуск unit/integration тестов под ASan/LSan/TSan.
Рекомендованный рабочий процесс (Dev + CI)
- В стадии разработки:
- Писать на безопасных языках там, где можно (Rust/Go/managed).
- Использовать смарт‑указатели, безопасные API и явные проверки.
- Локальные сборки с санитайзерами: $-fsanitize=address,undefined,leak,thread$ + отладочная оптимизация ($-O1$, $-g$).
- Интеграция фреймворма для fuzzing (libFuzzer) в тесты.
- Статический анализатор в IDE/в pre-commit.
- В CI/PR:
- Запуск статического анализа (CodeQL, Coverity, PVS-Studio) как часть PR.
- Собираемые и тестируемые конфигурации под санитайзерами (ASan/UBSan/TSan) в CI-пайплайне (можно как отдельный job, например GitHub Actions/GitLab CI).
- Nightly/periodic fuzzing (или использование OSS-Fuzz для инфраструктуры/критичных библиотек).
- Fail-fast политика: ошибки санитайзеров/фаззера — причина отклонить PR.
- Для релизов:
- Оставлять защитные механизмы на уровне бинаря: PIE, RELRO/Full RELRO, stack-protector, ASLR; strip символьную информацию в релизе, но хранить debuginfo отдельно для репортов крашей.
Короткая таблица какие инструменты за что
- Buffer overflow: AddressSanitizer, Valgrind, Clang Static Analyzer, libFuzzer/AFL.
- Integer overflow: UBSan ($-fsanitize=undefined$), статический анализ, fuzzing.
- Use-after-free: AddressSanitizer, Valgrind, TSan (в связке с гонками), debug-allocators.
Примеры команд (сборка тестов)
- Сборка с ASan и UBSan: clang/gcc с флагами $-fsanitize=address,undefined$ и $-g$, тесты запускаются в CI; при нахождении ошибок CI падает.
Заключение
- Лучшая стратегия — сочетать: безопасный язык там, где можно; в C/C++ — строгие API (smart pointers, bounds-checked), статический анализ в PR, динамические санитайзеры и фазы фуззинга в CI/nightly; включать системные защиты в релизных билдах.