Google продемонстрировал эксплуатацию уязвимостей Spectre через выполнение JavaScript в браузере

Компания Google опубликовала несколько прототипов эксплоитов, показывающих возможность эксплуатации уязвимостей класса Spectre при выполнении JavaScript-кода в браузере в обход ранее добавленных методов защиты. Эксплоиты могут использоваться для получения доступа к памяти процесса, выполняющего обработку web-контента в текущей вкладке. Для тестирования работы эксплоита запущен сайт leaky.page, а код с описанием логики работа размещён на GitHub.

Предложенный прототип рассчитан на совершение атаки на системы с процессорами Intel Core i7-6500U в окружении с Linux и Chrome 88. Для применения эксплоита для других окружений требуется внесение изменений. Метод эксплуатации не специфичен для процессоров Intel — после соответствующей адаптации была подтверждена работа эксплоита на системах с CPU других производителей, включая Apple M1 на базе архитектуры ARM. После незначительных корректировок эксплоит также работоспособен в других операционных системах и в других браузерах на базе движка Chromium.

В окружении на базе штатного Chrome 88 и процессоров Intel Skylake удалось добиться утечки данных из процесса, отвечающего за обработку web-контента в текущей вкладке Chrome (renderer process), со скоростью 1 килобайт в секунду. Дополнительно были разработаны альтернативные прототипы, например, эксплоит, позволяющий ценой уменьшения стабильности повысить скорость утечки до 8kB/s при использовании таймера performance.now() с точностью 5 микросекунд (0.005 миллисекунд). Также был подготовлен вариант, работающий при точности таймера на уровне одной миллисекунды, который мог использоваться для организации доступа к памяти другого процесса со скоростью около 60 байт в секунду.

Опубликованный демонстрационный код состоит из трёх частей. Первая часть выполняет калибровку таймера для оценки времени выполнения операций, необходимых для восстановления данных, оставшихся в процессорном кэше в результате спекулятивного выполнения инструкций CPU. Вторая часть производит определение раскладки памяти, используемой при размещении массива JavaScript.

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

Предложенная техника эксплуатации позволяет обойтись без высокоточных таймеров, доступных через API performance.now(), и без поддержки типа SharedArrayBuffer, позволяющего создавать массивы в разделяемой памяти. Эксплоит включает в себя гаджет Spectre, вызывающий контролируемое спекулятивное выполнение кода, и анализатор утечки по сторонним каналам, определяющий попавшие в кэш данные, полученные в ходе спекулятивного выполнения.

Гаджет реализован при помощи массива JavaScript, в котором предпринимается попытка доступа к области вне границ буфера, влияющая на состояние блока предсказания переходов из-за наличия добавленной компилятором проверки размера буфера (процессор забегая вперёд спекулятивно выполняет обращение, но откатывает состояние после проверки). Для анализа содержимого кэша в условиях недостаточной точности таймера предложен метод, обманывающий применяемую в процессорах стратегию вытеснения данных из кэша Tree-PLRU и позволяющий за счёт увеличения числа циклов значительно увеличить разницу во времени при отдаче значения из кэша и при отсутствии значения в кэше.

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

Для снижения риска владельцам сайтов предлагается использовать реализованные в последнее время заголовки Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X-Content-Type-Options и SameSite Cookie. Указанные механизмы напрямую не защищают от атак, но позволяют изолировать данные сайта от утечки в процессы, в которых может быть выполнен JavaScript-код атакующего (утечка происходит из памяти текущего процесса, в котором помимо кода атакующего могут обрабатываться и данные другого сайта, открытого в той же вкладке). Основная идея в том, чтобы разделить в разных процессах выполнение кода сайта от стороннего кода, получаемого из ненадёжных источников, например, включаемого через iframe.

Источник: opennet.ru