Содержание статьи
INFO
В 2007 году мы уже публиковали схожую подборку актуальных на тот момент угроз: «Кеш-атаки по сторонним каналам. Что произошло в области утечек на аппаратном уровне за последние два года».
О наиболее знаменитых атаках на процессоры читай в материале «Meltdown и Spectre. Разбираем фундаментальные уязвимости в процессорах».
О теории атак по сторонним каналам и их многочисленных разновидностях смотри статью «Обходные пути. Как атаки по сторонним каналам позволяют выкрадывать данные и обходить шифрование».
TLBleed: извлечение криптоключей
Атака TLBleed эксплуатирует микроархитектурную уязвимость буфера ассоциативной трансляции (TLB), который является неотъемлемой частью большинства современных процессоров. После ряда предварительных вычислений TLBleed способна вскрывать цифровые подписи EdDSA и без проблем извлекать их 256-битные ключи в 98% случаев. С чуть меньшим успехом (примерно 92%) TLBleed справляется с ключами RSA. Атака демонстрирует положительный результат даже при наличии современных средств защиты (CAT, TSX и других).
TLBleed исходит из того, что злодей имеет возможность выполнять непривилегированный код в целевой системе, чтобы отслеживать состояние разделяемого с жертвой буфера. Но ведь для этого нужно сначала прописаться по соседству с атакуемым процессом — на том же ядре ЦП! Насколько это реально?
В обычной среде выполнения добиться «совместного проживания» с процессом жертвы можно довольно-таки легко: привязав конкретный процесс к определенному ядру ЦП. В облачной среде это сделать сложнее, но тоже возможно, во многом благодаря тому, что облачные провайдеры склонны активировать в своих ЦП механизм гиперпоточности (например, EC2). Это распространенная практика увеличить производительность системы — чтобы разные виртуальные машины могли совместно использовать одни и те же ядра ЦП.
Таким образом, как только преступнику удается прописаться в том же ядре, где и жертва, будь то локально или в облаке, у него сразу появляется возможность провести атаку TLBleed.
Ret2spec: ошибочные спекуляции
Атака ret2spec по принципу действия схожа со Spectre и позволяет злоумышленникам спекулятивно выполнять произвольный код в любом процессе. Она дает реальную возможность извлекать конфиденциальные данные из чужого процесса или читать память за пределами песочницы компилятора JIT, если приложение выполняется в контексте браузера.
Ret2spec пользуется уязвимостью буфера стека возвратов (RSB) — у современных ЦП ключевого блока при предсказании адреса возврата. Атака реализуется в три этапа: сперва провоцируется ошибочное предсказание в RSB (на рисунке ниже схематично показано, как этого можно добиться). Затем спекулятивное выполнение перенаправляется на заранее расставленную цепочку инструкций. После чего остается только наладить канал обратной связи с обычной средой выполнения, чтобы сообщать туда результаты спекулятивных вычислений.
Для осуществления последнего этапа ret2spec использует секрето-зависимые обращения к памяти, которые модифицируют состояние кеша. Например, если атакующий хочет украсть значение регистра rax из чужого процесса, он при считывании памяти использует секретное значение в качестве смещения.
sh1 rax, 12
mov r8, [rbx + rax]
Это приводит к кешированию соответствующего адреса памяти rbx + rax * 4096, где 4096 — размер страницы в байтах. Затем, получив из rbx индекс кешированной страницы, хакер может узнать значение регистра rax. На этом этапе уже можно воспользоваться известными методами обходных каналов, такими как Flush + Reload или Prime + Probe.
LazyFP: читаем регистры FPU и SIMD
Атака LazyFP по своему принципу действия схожа с Meltdown. Основная цель этой атаки — взлом криптографических систем, опирающихся на инструкции Intel AES-NI, которые используются для аппаратного ускорения алгоритма шифрования AES.
LazyFP злоупотребляет «ленивым переключением контекста FPU», которое сегодня практикуется в популярных операционных системах и гипервизорах. Но, в отличие от Meltdown, LazyFP полагается на исключение #NM (Device Not Available), а не #PF (Page Fault). Почему #NM? Потому что именно оно и отвечает за реализацию механизма, оптимизирующего «ленивое переключение контекста».
Спекулятивное выполнение инструкций позволяет злодею полностью восстанавливать состояние регистров в блоке FPU атакуемого процесса — посредством непривилегированного локального кода. Чтобы получить достоверный снимок всего набора FPU-регистров жертвы (SIMD в том числе), преступнику нужен какой-то способ подавления генерации исключения #NM. Для этого LazyFP провоцирует другое исключение, которое можно перехватить и обработать до чтения регистров в FPU.
На рисунке ниже показан вариант подобного эксплоита. Он провоцирует ошибку страницы — как раз перед выполнением инструкции, затрагивающей состояние регистров. Для возможности восстановления после такого исключения LazyFP предусмотрительно конфигурирует обработчик соответствующего сигнала.
Здесь инструкция, затрагивающая состояние FPU, выполняется исключительно спекулятивно. Таким образом, прерывание, которое она генерирует, фактически никогда не возникает. Вместо этого атакующий получает сигнал, который он может обработать без остановки программы. ОС не видит исключения #NM и не обновляет FPU-регистры жертвы содержимым аппаратных регистров, поэтому они остаются нетронутыми и их содержимое можно извлечь. Примерно как при атаке Meltdown.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
