[ON] SWAPGS - новая уязвимость в механизме спекулятивного выполнения CPU

[rssbot]

Исследователи из компании Bitdefender выявили новую уязвимость (CVE-2019-1125) в механизме спекулятивного выполнения инструкций современных CPU, которая получила имя SWAPGS, соответствующее названию процессорной инструкции, вызывающей проблему. Уязвимость позволяет непривилегированному атакующему определить содержимое областей памяти ядра или запущенных виртуальных машин. Проблема подтверждена в процессорах Intel (x86_64) и частично затрагивает процессоры AMD, для которых не проявляется основной вектор атаки. Ранее реализованные методы противодействия уязвимостям Spectre и Meltdown не защищают от атаки SWAPGS при использовании процессоров Intel, но для Linux, ChromeOS, Android и Windows уже предложены исправления.

Уязвимость относится к классу Spectre v1 и основывается на идее восстановления данных из процессорного кэша, оставшихся после спекулятивного выполнения инструкций. Блоки предсказания переходов современных CPU для повышения производительности применяют упреждающее выполнение некоторых инструкций, которые вероятнее всего будут выполнены, но не дожидаясь вычисления всех факторов, определяющих их выполнение (например, когда ещё не вычислены условия перехода или параметры доступа). Если прогноз не подтверждается, процессор отбрасывает результат спекулятивного выполнения, но обработанные в его ходе данные оседают в процессорном кэше и могут быть восстановлены при помощи методов определения содержимого кэша по сторонним каналам, анализирующих изменение времени доступа к прокэшированным и не прокэшированным данным.

Особенность новой атаки в использовании утечки, возникающей в ходе спекулятивного выполнения инструкции SWAPGS, которая применяется в операционных системах для замены значения регистра GS при переходе управления из пространства пользователя в ядро ОС (используемое в пространстве пользователя значение GS заменяется на значение, используемое при операциях в ядре). В ядре Linux в GS хранится указатель per_cpu, используемый для доступа к данным ядра, а в пространстве пользователя указатели на TLS (Thread Local Storage).

Для исключения двойного вызова инструкции SWAPGS при повторном обращении к ядру из пространства ядра или когда выполняется код, не требующий замены регистра GS, перед инструкцией осуществляется проверка и условный переход. Механизм спекулятивного выполнения заранее переходит к выполнению кода с инструкцией SWAPGS, не дожидаясь результата проверки, и если выбранная ветка не подтвердилась, отбрасывает результат. Таким образом, может возникнуть ситуация, когда спекулятивно будет выбрана ветка не предусматривающая выполнение SWAPGS, но в процессе спекулятивного выполнения значение регистра GS будет изменено инструкцией SWAPGS и использовано в зависимых операциях с памятью, которые оседают в кэше CPU.

Исследователями предложено два сценария атаки, для которых подготовлены прототипы эксплоитов. Первый сценарий основывается на ситуации, когда инструкция SWAPGS не выполняется спекулятивно, хотя используется при фактическом выполнении, а второй - наоборот, когда инструкция SWAPGS выполняется спекулятивно, хотя фактически не должна. Для каждого сценария предусмотрено два варианта эксплуатации: атакующий может определить значение по определённому адресу в области ядра и атакующий может выполнить поиск определённого значения в по случайным адресам в ядре. Проведение атаки занимает много времени и для организации утечки может потребоваться выполнение эксплоита в течение нескольких часов.

В ядре Linux проблема устранена через изменение логики вызова инструкции SWAPGS (блокирование спекулятивного выполнения), по аналогии с исправлением других уязвимостей класса Spectre v1. Предполагается, что добавленная защита минимально повлияет на производительность типовых рабочих нагрузок. Задержка возникает на этапе переключения между пространством пользователя и ядра, что может привести к снижению производительности, например, при интенсивном выполнении системных вызовов из приложения или частой генерации NMI и прерываний.

Исправление требует установки обновления ядра как в основной системе, так и в гостевых окружениях, с последующей перезагрузкой системы. Для отключения защиты в Linux может быть использована опция "nospectre_v1", которая также отключает меры для блокирования уязвимости SWAPGS. Исправление доступно в виде патча для ядра Linux, который уже включён в состав выпусков 4.19.65, 5.2.7, 4.14.137, 4.9.188 и 4.4.188. Обновления для дистрибутивов Linux пока не выпущены (Debian, RHEL, Fedora, Arch Linux, SUSE/openSUSE, Ubuntu). В Windows проблема без лишней огласки была устранена в июльском обновлении. Компания Google подготовила исправление для ядра 4.19, поставляемого в ChromeOS и Android.

По заявлению исследователей из компании Bitdefender, Intel был информирован о проблеме ещё в августе прошлого года. Проблему было решено устранить программно, для чего к скоординированной выработке исправления были привлечены разработчики из Microsoft, Google и ядра Linux. Старые процессоры Intel, до Ivy Bridge, атаковать значительно труднее из-за отсутствия поддержки инструкции WRGSBASE, использованной в эксплоите. Системы ARM, POWER, SPARC, MIPS и RISC-V не подвержены проблеме, так как не поддерживают инструкцию SWAPGS.

Проблема угрожает главным образом обладателям процессоров Intel - на системах AMD удалось воспроизвести только второй сценарий атаки, ограничивающийся спекулятивной обработкой базового значения регистра GS, что можно использовать для поиска определённых значений в случайных областях памяти. Для блокирования данного варианта атаки достаточно существующих методов защиты от уязвимостей Spectre v1.


Источник: https://www.opennet.ru/opennews/art.shtml?num=51234
(opennet.ru, основная лента)

[azsx]

Может в компании amd наняли банду Сишников, что бы они разорили компанию intel?

[Hephaestus]

Может в компании amd наняли банду Сишников

Звучит так, как будто раньше там сишников не было, а были php-шники.

[Bizdelnick]

И каким боком тут вообще сишники?

[azsx]

И каким боком тут вообще сишники?

Наверное, кто проблемы в процессорах ищет немного знают С?

Звучит так, как будто раньше там сишников не было, а были php-шники.

Вот именно!

[Bizdelnick]

Наверное, кто проблемы в процессорах ищет немного знают С?

Зачем?

[azsx]

Зачем?

Не знаю что ответить.

[s.xbatob]

Проблема в архитектуре полувековой давности. Intel ещё тогда умирал, задавленный конкурентами.
А из архитектур уже тогда была Motorolla 68к и даже 88k с идеологией RISC

[Bizdelnick]

Проблема в архитектуре полувековой давности. Intel ещё тогда умирал, задавленный конкурентами.
А из архитектур уже тогда была Motorolla 68к и даже 88k с идеологией RISC

Можно подумать, в RISC-архитектурах не используется спекулятивное выполнение.

[s.xbatob]

Bizdelnick
Ну, не так нагло. Я вообще не знаю, где кончается конвейер, и где начинаются предсказания (от Ванги?)
Конечно, когда любой jump отрабатывает через команду, неудобно. Зато честно.

Добавлено (18:15):

кстати, порядка полутора вольт питание (зато ток сотни ампер, что отдельная, но тяжёлая проблема) -- там что за технология? I2C?