CROSSTalk — уязвимость в CPU Intel, приводящая к утечке данных между ядрами
9 июня 2020 года
Группа исследователей из Амстердамского свободного университета выявила новую уязвимость (CVE-2020-0543) в микроархитектурных структурах процессоров Intel, примечательную тем, что она позволяет восстановить результаты выполнения некоторых инструкций, выполняемых на другом ядре CPU. Это первая уязвимость механизма спекулятивного выполнения инструкций, допускающая утечку данных между отдельными ядрами CPU (ранее утечки ограничивались разными потоками одного ядра). Исследователи присвоили проблеме имя CROSSTalk, но в документах Intel уязвимость упоминается как SRBDS (Special Register Buffer Data Sampling).
Уязвимость относится к представленному год назад классу проблем MDS (Microarchitectural Data Sampling) и основывается на применении методов анализа по сторонним каналам к данным в микроархитектурных структурах. Принцип действия CROSSTalk близок к уязвимости RIDL, но отличается источником утечки. Методы определения содержимого микроархитектурных структур манипулируют тем, что при спекулятивной обработке исключений (fault) или операций load и store содержимое внутренних структур перенаправляется для обработки в регистры или кэш. Спекулятивные операции не завершаются и результат отбрасывается, но перенаправленное содержимое можно определить при помощи методов анализа кэша по сторонним каналам. Новая уязвимость манипулирует утечкой из ранее недокументированного промежуточного буфера, который используется совместно всеми ядрами CPU.
Суть проблемы в том, что некоторые инструкции микропроцессора, включая RDRAND, RDSEED и SGX EGETKEY, реализованы с использованием внутренней микрооперации ( μop) SRR (Special Register Reads). На подверженных уязвимости процессорах данные, возвращаемые для SRR, оседают в промежуточном буфере, общем для всех ядер CPU, после чего передаются в буфер заполнения (LFB, Line Fill Buffer), привязанный к конкретному физическому ядру CPU на котором инициирована операция чтения. Далее, из буфера заполнения значение копируется в регистры, видимые приложениям.
Размер промежуточного совместного буфера соответствует линии кеша, что обычно больше, чем размер читаемых данных и разные операции чтения затрагивают разные смещения в буфере. Так как совместный буфер копируется в буфер заполнения целиком, то перемещается не только нужная для текущей операции порция, но и данные, оставшиеся от выполнения других операций, в том числе выполненных на других ядрах CPU.
В случае успешной организации атаки, аутентифицированный в системе локальный пользователь может определить результат выполнения инструкций RDRAND, RDSEED и EGETKEY в чужом процессе, в том числе запущенном в другом виртуальном окружении или внутри анклава Intel SGX, независимо от ядра CPU, на котором выполняется код. Выявившие проблему исследователи опубликовали прототип эксплоита, демонстрирующий возможность утечки сведений о случайных значениях, получаемых через инструкции RDRAND и RDSEED, для восстановления закрытого ключа ECDSA, обрабатываемого в анклаве Intel SGX, после осуществления в системе всего одной операции с цифровой подписью.
Проблеме подвержен широкий спектр настольных, мобильных и серверных процессоров Intel, включая Core i3, i5, i7, i9, m3, Celeron (серии J, G и N), Atom (серии С, E и X), Xeon (семейства E3, E5, E7, W и D), Xeon Scalable и т.д. Примечательно, что компания Intel была уведомлена об уязвимости в сентябре 2018 года, а в июле 2019 года был предоставлен прототип эксплоита, демонстрирующий утечку данных между ядрами CPU, но разработка исправления затянулась из-за сложности его реализации.
В предложенном сегодня обновлении микрокода проблема блокирована путём изменения поведения инструкций RDRAND, RDSEED и EGETKEY для избыточной перезаписи данных в совместном буфере для недопущения оседания в нём остаточной информации. Кроме того, применена приостановка обращения к буферу до завершения операций чтения и перезаписи содержимого. Пакеты с обновлением микрокода уже предложены в дистрибутивах
Источники
править
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
