CROSSTalk об уязвимости утечки данных, а что, если ... она затрагивает Intel

Intel-ошибка

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

И это команда исследователей из Свободного университета Амстердама ha обнаружил новую уязвимость (CVE-2020-0543) в микроархитектурных структурах процессоров Intel, что примечательно тем, что позволяет восстановить результаты некоторых инструкций работать на другом ядре ЦП.

Это первая уязвимость механизма спекулятивного исполнения инструкций, возможность утечки данных между отдельными ядрами ЦП (Раньше утечки ограничивались разными потоками ядра.)

Intel-ошибка
Теме статьи:
В процессорах Intel обнаружена новая уязвимость, которую нельзя исправить

Исследователи они назвали проблему CROSSTalk, но в документации Intel эта уязвимость упоминается как SRBDS (Sample Special Register Buffer Data).

О CROSSTalk

Уязвимость относится к классу проблем MDS, введенному год назад, и основан на применении сторонних методов анализа данным в микроархитектурных структурах.

Принцип CROSSTalk близка к уязвимости RIDL, но отличается источником утечки. Новая уязвимость управляет промежуточной утечкой буфера ранее недокументированный который распределяется между всеми ядрами ЦП.

Суть проблемы в том, что некоторые инструкции микропроцессора, включая RDRAND, RDSEED и SGX EGETKEY, реализуются с использованием внутренней микроархитектуры SRR (Special Register Reads).

На уязвимых процессорах данные, возвращаемые для SRR, помещаются в промежуточный буфер, общий для всех ядер ЦП, после чего они передаются в буфер заполнения, связанный с конкретным физическим ядром ЦП, на котором ЦП запускает операцию чтения. Затем из буфера заполнения значение копируется в регистры, видимые приложениям.

Размер промежуточного общего буфера соответствует строке кешачто обычно больше, чем размер прочитанных данных и разные операции чтения влияют на разные смещения в буфере.

Поскольку общий буфер копируется во весь буфер заполнения, перемещается не только часть, необходимая для текущей операции, но и оставшиеся данные от других операций, в том числе выполняемых на других ядрах ЦП.

Если атака организована успешно, локальный пользователь аутентифицирован в системе может определить результат выполнение инструкций RDRAND, RDSEED и EGETKEY в странном процессе или в анклаве Intel SGX, независимо от ядра процессора, на котором выполняется код.

Исследователи кто обнаружил проблему опубликовал прототип эксплойта, который продемонстрировал возможность утечки информации на случайных значениях, полученных с помощью инструкций RDRAND и RDSEED, для восстановления закрытого ключа ECDSA, обработанного в анклаве Intel SGX, после выполнения только одной операции с цифровой подписью в системе.

Это продемонстрировало, что широкий спектр процессоров Intel для настольных, мобильных и серверных компьютеров, включая Core i3, i5, i7, i9, m3, Celeron, Atom, Xeon, Scalable Xeon и т. Д., Уязвим.

Примечательно, что Intel была уведомлена об уязвимости в сентябре 2018 г. В июле 2019 года был представлен прототип эксплойта, который показал утечку данных между ядрами ЦП, но разработка решения была отложена из-за сложности его реализации.

В предлагаемом сегодня обновлении микрокода проблема блокируется изменением поведения инструкций RDRAND, RDSEED и EGETKEY для перезаписи данных в общем буфере, чтобы предотвратить оседание в нем остаточной информации.

Кроме того, приостановка доступа к буферу применяется до завершения операций чтения и записи.

Побочный эффект этой защиты увеличение задержек когда выполняются RDRAND, RDSEED и EGETKEY, и снижение производительности при попытке выполнить эти инструкции одновременно на разных логических процессорах. Эти функции могут отрицательно повлиять на производительность некоторых приложений.

источник: https://www.vusec.net

intel-zombieload
Теме статьи:
Zombieload 2.0 - новый метод атаки, затрагивающий только процессоры Intel

Комментарий, оставьте свой

Оставьте свой комментарий

Ваш электронный адрес не будет опубликован. Обязательные для заполнения поля помечены *

*

*

  1. Ответственный за данные: AB Internet Networks 2008 SL
  2. Назначение данных: контроль спама, управление комментариями.
  3. Легитимация: ваше согласие
  4. Передача данных: данные не будут переданы третьим лицам, кроме как по закону.
  5. Хранение данных: база данных, размещенная в Occentus Networks (ЕС)
  6. Права: в любое время вы можете ограничить, восстановить и удалить свою информацию.

  1.   Nacho сказал

    Заголовок не понимается, там, где идут три точки, должна стоять запятая, и да, это «да» имеет ударение.