CROSSTalk - уязвимость в CPU Intel приводящая к утечке данных между ядрами
10.06.20
Группа исследователей из Амстердамского свободного университета выявила новую уязвимость (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, реализованы с использованием внутренней микроархитекстурной операции 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 для избыточной перезаписи данных в совместном буфере для недопущения оседания в нём остаточной информации. Кроме того, применена приостановка обращения к буферу до завершения операций чтения и перезаписи содержимого. Пакеты с обновлением микрокода уже предложены в дистрибутивах Debian, Ubuntu, RHEL, SUSE, Fedora.
Побочным эффектом подобной защиты является увеличение задержек при выполнении RDRAND, RDSEED и EGETKEY, и сокращение пропускной способности при попытке одновременного выполнения данных инструкций на разных логических процессорах. Выполнение RDRAND, RDSEED и EGETKEY также приостанавливает доступ к памяти из других логических процессоров. Указанные особенности могут негативно повлиять на производительность некоторых серверных приложений, поэтому в прошивке предусмотрен механизм (RNGDS_MITG_DIS) для отключения защиты инструкций RDRAND и RDSEED, выполняемых вне анклава Intel SGX.
OpenNet
10.06.20
Группа исследователей из Амстердамского свободного университета выявила новую уязвимость (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, реализованы с использованием внутренней микроархитекстурной операции 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 для избыточной перезаписи данных в совместном буфере для недопущения оседания в нём остаточной информации. Кроме того, применена приостановка обращения к буферу до завершения операций чтения и перезаписи содержимого. Пакеты с обновлением микрокода уже предложены в дистрибутивах Debian, Ubuntu, RHEL, SUSE, Fedora.
Побочным эффектом подобной защиты является увеличение задержек при выполнении RDRAND, RDSEED и EGETKEY, и сокращение пропускной способности при попытке одновременного выполнения данных инструкций на разных логических процессорах. Выполнение RDRAND, RDSEED и EGETKEY также приостанавливает доступ к памяти из других логических процессоров. Указанные особенности могут негативно повлиять на производительность некоторых серверных приложений, поэтому в прошивке предусмотрен механизм (RNGDS_MITG_DIS) для отключения защиты инструкций RDRAND и RDSEED, выполняемых вне анклава Intel SGX.
OpenNet
