На прошлой неделе компания Intel выпустила бюллетень, посвященный уязвимости в процессорах, начиная с поколения Ice Lake 2019 года (десятое поколение Intel Core). Как следует из описания, «определенная последовательность инструкций может приводить к нестандартному поведению». Довольно часто эти сухие слова — все, что мы узнаем о какой-либо проблеме, но в данном случае у нас есть подробное описание уязвимости от команды исследователей Google во главе с Тависом Орманди (краткий пересказ исследования также есть в этой новости на Хабре).



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

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



Префикс rex используется для работы с регистрами процессора, и не во всех случаях, а для обращения к 8 дополнительным регистрам, внедренным в архитектуре x86_64. К инструкции movsb этот префикс не имеет никакого отношения. Поведение процессора при наличии префикса меняется из-за технологии Fast Short Repeat Move, внедренной в 2019 году именно в поколении процессоров Intel Ice Lake. Технология FSRM ускоряет рутинные операции работы с данными (конкретно перенос данных небольшими блоками) и влияет как раз на такие инструкции, как movsb.

Баг был обнаружен благодаря исследованиям Орманди и его коллег в области «фаззинга процессоров». Ранее мы писали про еще один результат этих исследований — уязвимость Zenbleed в процессорах AMD Zen 2. Если коротко, фаззинг для поиска проблем в процессорах генерирует случайный код, который затем выполняется на двух разных системах. По логике результат работы одной и той же программы должен быть одинаковый. Поэтому отличия в исполнении кода на разном железе как раз и могут указывать на нештатную работу.

В чем заключается «нештатность» работы процессоров Intel? Исследователи наблюдали большой ассортимент глюков, начиная с неожиданных переходов к выполнению случайного набора инструкций. В случае эксплуатации бага одновременно на нескольких ядрах процессора можно добиться состояния machine-check exception или, если проще, отказа в обслуживании. Проверить собственный процессор можно с помощью PoC, подготовленного специалистами Google.

Именно возможность провести DoS-атаку делает эту аппаратную проблему достаточно серьезной, особенно для облачных провайдеров. На момент подготовки статьи Intel уже выпустила обновление микрокода, закрывающее проблему, для наиболее современных процессоров Intel 12-го и 13-го поколений. Патч для процессоров 10-го и 11-го поколений готовится. Примечательно, что исследователи из Google не говорят о возможности эксплуатации уязвимости для выполнения произвольного кода — уж слишком непредсказуемо поведение процессора. Но Intel, которая определенно знает о проблеме больше, чем независимые специалисты, в бюллетене прямо указывает на потенциальную эскалацию привилегий и доступ к секретной информации.

Что еще произошло:

Эксперты «Лаборатории Касперского» открывают сезон подведения итогов года статьей с предсказаниями по развитию продвинутых угроз.

Ряд ошибок в опенсорсной библиотеке BitcoinJS привели к тому, что кошельки Bitcoin, сгенерированные с 2011 по 2015 год, могут быть достаточно легко взломаны.

Свежая исследовательская работа ставит под сомнение стойкость шифрования при подключении по протоколу SSH, если во время установки соединения происходят ошибки вычисления.

Комментарии (6)


  1. Keeper10
    20.11.2023 14:21
    +1

    Решето!


  1. S-trace
    20.11.2023 14:21
    +1

    Примечательно, что исследователи из Google не говорят о возможности эксплуатации уязвимости для выполнения произвольного кода — уж слишком непредсказуемо поведение процессора.

    А не говорят они о выполнении произвольного кода через эту уязвимость потому, что чтобы её проэксплуатировать нужно выполнить произвольный код, как ни странно.


  1. domix32
    20.11.2023 14:21

    до полного отказа в обслуживании

    Простите, что? Процессор отказывается обслужить?


    1. S-trace
      20.11.2023 14:21
      +2

      Да. "Отказ в обслуживании" значит, что что-то сломалось и не работает больше. Стандартный термин. В данном случае ломается и перестаёт выполнять задачи сам процессор.


      1. domix32
        20.11.2023 14:21

        Я только сейчас понял что вы Denial of Service на русский перевели. DoS это всё же отвал системы по причине поломки процессора, а в случае с процессором это всё же отказ оборудования, а не сервиса.


  1. s_e_k_a_i
    20.11.2023 14:21

    Везёт мне с моим I5....