Security Week 2347: уязвимость в процессорах Intel
На прошлой неделе компания 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, если во время установки соединения происходят ошибки вычисления.
