SFOP: как атака через segmentation fault обходит защиту Intel CET в Linux

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

Такой подход отличается от классических техник вроде Return‑Oriented Programming (ROP). В ROP атакующий манипулирует адресами возврата на стеке, а в SFOP управление передаётся через повторяющиеся события обработки сбоев.

Почему Intel CET должен был предотвратить подобные атаки

Intel разработала Control‑Flow Enforcement Technology (CET) как аппаратную защиту от атак повторного использования кода. Технология включает несколько механизмов контроля выполнения программы, включая проверку адресов возврата и ограничения для косвенных переходов.

Главная цель CET — не позволить злоумышленнику перенаправлять поток выполнения программы на произвольные инструкции внутри уже существующего кода.

Однако CET ориентирована прежде всего на некорректные переходы внутри обычного выполнения программы.

Атака SFOP использует другой путь: она опирается на легитимные механизмы операционной системы, которые CET не блокирует.

Как SFOP обходит CET в Linux

Ключевая идея атаки заключается в том, что доставка сигнала операционной системой является допустимым переходом управления.

Схема работы атаки примерно следующая:

1. Эксплойт заставляет программу обратиться к защищённой области памяти.
2. Возникает segmentation fault.
3. Ядро Linux отправляет сигнал SIGSEGV и передаёт управление обработчику сигнала.
4. Обработчик выполняет контролируемое действие и готовит следующий сбой.

После этого процесс повторяется.

Таким образом, каждый вызов обработчика сигнала становится контролируемым шагом в цепочке исполнения. Поскольку переход к обработчику выполняется через официальный механизм операционной системы, он может обходить ограничения CET, предназначенные для защиты косвенных переходов и возвратов.

Со временем цепочка таких событий может позволить атакующему добиться произвольного выполнения кода, используя уже существующие компоненты программы.

Роль механизма сигналов SIGSEGV в Linux

В Linux приложения могут регистрировать собственные обработчики для сигналов, включая SIGSEGV. Обычно они используются для:

• записи ошибок в журнал
• попытки восстановить работу программы
• диагностики сбоев

SFOP превращает этот механизм в инструмент атаки. Злоумышленник:

• многократно вызывает segmentation fault
• каждый раз запускает обработчик сигнала
• изменяет состояние программы перед следующим сбоем

В результате обработчики сигналов становятся повторно используемым строительным блоком управления потоком выполнения.

Предлагаемые меры защиты

Исследователи предложили несколько направлений защиты от атак класса SFOP.

Усиление безопасности ядра Linux

Один из вариантов — изменить поведение обработки сигналов в ядре Linux, чтобы злоумышленники не могли использовать последовательные segmentation fault как примитив управления выполнением.

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

Дополнительный слой защиты PLaTypus

Другим предложенным механизмом является PLaTypus — исследовательский слой усиления защиты, разработанный для повышения эффективности CET.

Исследователи заметили, что даже при включённом CET злоумышленники могут перенаправлять выполнение между функциями разных библиотек программы.

PLaTypus решает эту проблему, ограничивая косвенные переходы:

• переходы в основном остаются в пределах одной библиотеки;
• переходы между библиотеками допускаются только в строго контролируемых случаях.

Это значительно уменьшает число возможных «гаджетов» для атак повторного использования кода и тем самым снижает поверхность атаки.

Почему это исследование важно

Работа по SFOP показывает важный принцип современной кибербезопасности: аппаратная защита сама по себе не гарантирует полной безопасности.

Если операционная система или программная среда предоставляет легитимные механизмы передачи управления, злоумышленники могут попытаться превратить их в новые примитивы атаки.

Поэтому эффективная защита должна учитывать весь стек технологий — от архитектуры процессора до внутренней логики операционной системы.