Группа исследователей из Амстердамского свободного университета и компании IBM разработала новый вариант атаки на механизм спекулятивного выполнения в современных процессорах, получивший кодовое имя GhostRace (CVE-2024-2193). Проблема проявляется в процессорах, производимых компаниями Intel, AMD, ARM и IBM. Для демонстрации принципов проведения атаки опубликован прототип эксплоита, позволяющий извлекать данные из памяти ядра Linux с производительностью 12 Кб в секунду при уровне надёжности, типичном для атак класса Spectre. При проведении атак на системы виртуализации, атакующий из гостевой системы может определить содержимое памяти хост-окружения или других гостевых систем.
Предложенный метод атаки манипулирует возникновением в спекулятивном режиме состояний гонки, способных привести к обращению к уже освобождённым областям памяти, в случае неверного прогнозирования процессором ветвления в коде, в котором осуществляются условные операции с примитивами синхронизации потоков, такими как mutex и spinlock. Возникающие спекулятивные обращения к памяти после определения неверного предсказания отбрасываются процессором, но следы их выполнения оседают в процессорном кэше и могут затем быть извлечены при помощи анализа по сторонним каналам.
По аналогии с эксплуатацией уязвимостей Spectre v1 для осуществления атаки GhostRace требуется наличие в ядре определённых последовательностей инструкций (гаджетов), приводящих к спекулятивному выполнению кода в зависимости от внешних условий, на которые может влиять атакующий. В целях оптимизации процессор начинает выполнять подобные гаджеты в спекулятивном режиме, но потом определяет, что предсказание ветвления не оправдалось и откатывает операции в исходное состояние.
Гаджет образуется, например, из участков кода, в которых состояние проверяется в бесконечном цикле и осуществляется выход из цикла после снятия блокировки доступа к ресурсу. Соответственно, при спекулятивном выполнении инструкций можно добиться ложного срабатывания перехода и выполнения защищённого блокировкой набора инструкций, несмотря на то, что фактически блокировка ресурса остаётся неснятой.
При анализе кода ядра Linux 5.15.83 исследователями выявлено 1283 гаджета, приводящих к спекулятивному обращению к уже освобождённой памяти (SCUAF — Speculative Concurrent Use-After-Free). Потенциально атака может быть совершена на системы виртуализации, любые ядра ОС и программы, в которых примитивы синхронизации потоков проверяются с использованием условных операторов, а код выполняется на платформах допускающих спекулятивное выполнение операций ветвления (x86, ARM, RISC-V и т.п.).
Для блокирования атаки предлагается использовать сериализацию примитивов синхронизации, т.е. добавление процессорной инструкции LFENCE после команды cmpxchq, проверяющей состояние блокировки. Предложенный для включения в ядро Linux метод защиты приводит к снижению производительности приблизительно на 5% при прохождении теста LMBench, так как вызов LFENCE запрещает упреждающее выполнение следующих инструкций, до того как будет завершена фиксация всех предыдущих операций.
Разработчики ядра Linux и компании-производители CPU были уведомлены о проблеме в конце 2023 года. Компания AMD опубликовала отчёт о наличии уязвимости, в котором рекомендовала использовать типовые приёмы защиты от атак класса Spectre v1. Компании Intel и ARM пока не отреагировали. Разработчики ядра Linux в ближайшем будущем не намерены использовать предложенный метод сериализации примитивов синхронизации из-за снижения производительности, но уже реализовали необходимые ограничения для защиты от сопутствующей техники эксплуатации IPI Storming (Inter-Process Interrupt Storming) (CVE-2024-26602), которая применяется в эксплоите для прерывания процесса в нужный момент (наводнение ядра CPU прерываниями, мешающими завершению сработавшего во время работы процесса обработчика прерываний) с целью предоставления временного окна для осуществления спекулятивного обращения к уже освобождённой памяти.
Несмотря на то что в гипервизоре Xen пока не выявлено вызывающие утечку гаджеты, разработчики Xen подготовили изменения с реализацией защищённого механизма блокировок LOCK_HARDEN, похожего на ранее добавленный метод защиты BRANCH_HARDEN. Из-за возможного негативного влияния на производительность, а также отсутствия подтверждений возможности совершения атаки на Xen, режим LOCK_HARDEN отключён по умолчанию.
Источник: https://www.opennet.ru/opennews/art.shtml?num=60781