Reptar: уязвимость в процессорах Intel

14 ноября компания Google выпустила бюллетень, в котором сообщила о серьезной уязвимости в ряде процессоров компании Intel, начиная с поколения Ice Lake, выпущенного в 2019 году. Потенциально, эта уязвимость может приводить к отказу в обслуживании, эскалации привилегий или раскрытию чувствительной информации. На момент подготовки статьи обновления микрокода, закрывающие проблему, были выпущены для 12-го и 13-го поколений процессоров Intel (соответственно, Alder Lake и Raptor Lake). Патчи для процессоров 10-го и 11-го поколений (Ice Lake и Tiger Lake) готовятся. Полный список подверженных процессоров представлен на сайте Intel в виде огромной таблицы.

По словам представителей Intel, о нестандартном поведении процессоров инженеры компании знали, но проблема считалась некритичной, и ее решение отложили на первую половину 2024 года. Но ситуация изменилась, когда исследователи из компании Google, независимо от Intel, обнаружили проблему. Собственно, все детали уязвимости мы знаем от специалистов Google, а конкретно из статьи Тависа Орманди.

Фаззинг процессоров

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

Фаззинг — это метод, который подразумевает подачу случайной информации на ввод тестируемой информационной системы. Как правило, ее применяют для автоматизированного поиска уязвимостей в софте: создается специальная «оснастка», позволяющая взаимодействовать с программой и отслеживать ее состояние. Дальше происходят десятки и сотни тысяч тестов, в ходе которых можно обнаружить нестандартное поведение тестируемого кода.

В случае испытания процессоров все несколько сложнее. Мы должны генерировать случайные программы, которые при этом работают без собственных сбоев, и выполнять их на процессоре. Как в таком случае отделить штатное поведение процессора от аномального? Ведь далеко не всегда ошибка в процессе выполнения ПО приводит к сбою. Орманди предложил методику, в рамках которой одинаковый «случайный» код одновременно выполняется на разных процессорах. По идее, результат работы одной и той же программы должен быть одинаковый, а вот если результат отличается, то возможно это признак проблемы. Именно такой подход выявил проблему в процессорах Intel.

Бесполезный, но опасный код

Чтобы понять, как работает уязвимость Reptar, нужно спуститься на самый низкий уровень программирования, где речь идет о машинных кодах, непосредственно исполняемых процессорами. Для более удобного представления таких базовых команд используется язык ассемблера. Кусок программы на ассемблере выглядит примерно так:

Пример кода на языке ассемблера. В последней строчке виден префикс, модифицирующий выполнение следующей за ним команды. Источник

В последней строке использована инструкция movsb, дающая процессору команду переместить данные из одной области памяти в другую. Перед ней стоит модификатор rep, который указывает на то, что команду movsb нужно выполнить несколько раз подряд. Такие префиксы актуальны далеко не для всех команд. Процессоры Intel умеют пропускать бессмысленные префиксы. Тавис Орманди приводит такой пример:

Множество повторяющихся префиксов не приведут к ошибке при выполнении программы. Источник

Давайте добавим еще один префикс, так называемый rex.rxb. Он был введен с появлением архитектуры x86-64 для работы с восемью дополнительными процессорными регистрами. Впрочем, не так важно, что именно он делает. Нам достаточно знать, что этот префикс не имеет смысла при использовании с командой movsb:

В теории префикс rex.rxb должен быть пропущен, а выполнена только команда movsb с префиксом rep. Но на практике процессоры Intel ведут себя по-другому. Источник

Но по факту наличие этого префикса поменяет поведение процессора Intel (начиная с Ice Lake), хотя и не должно. В процессорах этого поколения была добавлена технология, известная как Fast Short Repeat Move. Она направлена на ускорение операций по перемещению данных в оперативной памяти. В том числе эта технология может оптимизировать выполнение инструкции rep movsb. Вместе с фичей Fast Short Repeat Move в логику работы процессора закралась ошибка, которую сначала нашли инженеры Intel, а потом и специалисты Google.

Непосредственная угроза

К чему может привести выполнение этой ломающей нормальное поведение процессора инструкции? Орманди пишет о непредсказуемых результатах. Исследователи наблюдали исполнение случайного кода, игнорирование частей программы, разнообразные сбои в работе процессора вплоть до полного отказа. Для последнего нужно каким-то образом задействовать уязвимость на паре процессорных ядер одновременно. Для проверки собственных систем на наличие уязвимости командой исследователей Google была подготовлена тестовая программа.

Непредсказуемое поведение — это уже достаточно плохо. Самым важным отличием данного «процессорного бага» от всех остальных является то, что он непосредственно угрожает, в первую очередь, поставщикам услуг хостинга виртуальных частных серверов или в целом поставщикам «облачных решений». Этот бизнес построен на возможности разделить один мощный сервер между десятками или сотнями клиентов, каждый из которых будет управлять собственной виртуальной операционной системой. Важно, что клиент ни при каких обстоятельствах не должен видеть данные другого клиента, либо данные хоста — операционной системы, управляющей виртуальными контейнерами.

А теперь представьте, что клиент может выполнить в своей виртуальной ОС программу, которая приведет к падению хоста. Как минимум это способ провести DoS-атаку в отношении провайдера. Собственно, Орманди других вариантов эксплуатации проблемы и не привел, ссылаясь на то, что просчитать поведение процессора, работающего в режиме «черного ящика», очень сложно. Хотя теоретически возможно добиться выполнения, например, нужного атакующему кода вместо случайных сбоев. Представители Intel сами говорят о том, что «выполнение кода» и «раскрытие информации» возможны. Поэтому компаниям, предоставляющим услуги виртуального хостинга, крайне важно установить обновления микрокода, подготовленные компанией Intel.