Suicide
15.03.2021, 20:01
Компания Google опубликовала (https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html) несколько прототипов эксплоитов, показывающих возможность эксплуатации уязвимостей класса Spectre при выполнении JavaScript-кода в браузере в обход ранее добавленных методов защиты. Эксплоиты могут использоваться для получения доступа к памяти процесса, выполняющего обработку web-контента в текущей вкладке. Для тестирования работы эксплоита запущен сайт leaky.page (https://leaky.page/), а код с описанием логики работа размещён (https://github.com/google/security-research-pocs/tree/master/spectre.js) на GitHub.
Предложенный прототип рассчитан на совершение атаки на системы с процессорами Intel Core i7-6500U в окружении с Linux и Chrome 88. Для применения эксплоита для других окружений требуется внесение изменений. Метод эксплуатации не специфичен для процессоров Intel - после соответствующей адаптации была подтверждена работа эксплоита на системах с CPU других производителей, включая Apple M1 на базе архитектуры ARM. После незначительных корректировок эксплоит также работоспособен в других операционных системах и в других браузерах на базе движка Chromium.
В окружении на базе штатного Chrome 88 и процессоров Intel Skylake удалось добиться утечки данных из процесса, отвечающего за обработку web-контента в текущей вкладке Chrome (renderer process (https://developers.google.com/web/updates/2018/09/inside-browser-part3#renderer_processes_handle_web_contents)), со скоростью 1 килобайт в секунду. Дополнительно были разработаны альтернативные прототипы, например, эксплоит, позволяющий ценой уменьшения стабильности повысить скорость утечки до 8kB/s при использовании таймера performance.now() с точностью 5 микросекунд (0.005 миллисекунд). Также был подготовлен вариант, работающий при точности таймера на уровне одной миллисекунды, который мог использоваться для организации доступа к памяти другого процесса со скоростью около 60 байт в секунду.
Опубликованный демонстрационный код состоит из трёх частей. Первая часть выполняет калибровку таймера для оценки времени выполнения операций, необходимых для восстановления данных, оставшихся в процессорном кэше в результате спекулятивного выполнения инструкций CPU. Вторая часть производит определение раскладки памяти, используемой при размещении массива JavaScript.
Третья часть непосредственно выполняет эксплуатацию уязвимости Spectre (https://www.opennet.ru/keywords/spectre.html) для определения содержимого памяти текущего процесса в результате создания условий для спекулятивного выполнения определённых операций, результат которых отбрасывается процессором после определения неудачного прогноза, но следы выполнения оседают в общем кэше и могут быть восстановлены при помощи методов определения содержимого кэша по сторонним каналам, анализирующих изменение времени доступа к прокэшированным и не прокэшированным данным.
Предложенная техника эксплуатации позволяет обойтись без высокоточных таймеров, доступных через API performance.now() (https://developer.mozilla.org/en-US/docs/Web/API/Performance/now), и без поддержки типа SharedArrayBuffer (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer), позволяющего создавать массивы в разделяемой памяти. Эксплоит включает в себя гаджет Spectre, вызывающий контролируемое спекулятивное выполнение кода, и анализатор утечки по сторонним каналам, определяющий попавшие в кэш данные, полученные в ходе спекулятивного выполнения.
Гаджет реализован при помощи массива JavaScript, в котором предпринимается попытка доступа к области вне границ буфера, влияющая на состояние блока предсказания переходов из-за наличия добавленной компилятором проверки размера буфера (процессор забегая вперёд спекулятивно выполняет обращение, но откатывает состояние после проверки). Для анализа содержимого кэша в условиях недостаточной точности таймера предложен метод (https://leaky.page/plru.html), обманывающий применяемую в процессорах стратегию вытеснения данных из кэша Tree-PLRU (https://en.wikipedia.org/wiki/Pseudo-LRU#Tree-PLRU) и позволяющий за счёт увеличения числа циклов значительно увеличить разницу во времени при отдаче значения из кэша и при отсутствии значения в кэше.
Отмечается, что компания Google опубликовала прототип эксплоита для того чтобы показать реалистичность атак с использованием уязвимостей класса Spectre и для стимулирования web-разработчиков для применения техник, минимизирующих риски от подобных атак. При этом Google считает, что без существенной переработки предложенного прототипа невозможно создать универсальные эксплоиты, готовые не только для демонстрации, но и для повсеместного применения.
Для снижения риска владельцам сайтов предлагается (https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html) использовать реализованные в последнее время заголовки Cross-Origin Opener Policy (COOP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy)), Cross-Origin Embedder Policy (COEP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy)), Cross-Origin Resource Policy (CORP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy)), Fetch Metadata Request (https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header), X-Frame-Options (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options), X-Content-Type-Options (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) и SameSite Cookie (https://web.dev/samesite-cookies-explained/). Указанные механизмы напрямую не защищают от атак, но позволяют изолировать данные сайта от утечки (https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md#introduction) в процессы, в которых может быть выполнен JavaScript-код атакующего (утечка происходит из памяти текущего процесса, в котором помимо кода атакующего могут обрабатываться и данные другого сайта, открытого в той же вкладке). Основная идея в том, чтобы разделить в разных процессах выполнение кода сайта от стороннего кода, получаемого из ненадёжных источников, например, включаемого через iframe.
13.03.2021
https://www.opennet.ru/opennews/art.shtml?num=54751
Предложенный прототип рассчитан на совершение атаки на системы с процессорами Intel Core i7-6500U в окружении с Linux и Chrome 88. Для применения эксплоита для других окружений требуется внесение изменений. Метод эксплуатации не специфичен для процессоров Intel - после соответствующей адаптации была подтверждена работа эксплоита на системах с CPU других производителей, включая Apple M1 на базе архитектуры ARM. После незначительных корректировок эксплоит также работоспособен в других операционных системах и в других браузерах на базе движка Chromium.
В окружении на базе штатного Chrome 88 и процессоров Intel Skylake удалось добиться утечки данных из процесса, отвечающего за обработку web-контента в текущей вкладке Chrome (renderer process (https://developers.google.com/web/updates/2018/09/inside-browser-part3#renderer_processes_handle_web_contents)), со скоростью 1 килобайт в секунду. Дополнительно были разработаны альтернативные прототипы, например, эксплоит, позволяющий ценой уменьшения стабильности повысить скорость утечки до 8kB/s при использовании таймера performance.now() с точностью 5 микросекунд (0.005 миллисекунд). Также был подготовлен вариант, работающий при точности таймера на уровне одной миллисекунды, который мог использоваться для организации доступа к памяти другого процесса со скоростью около 60 байт в секунду.
Опубликованный демонстрационный код состоит из трёх частей. Первая часть выполняет калибровку таймера для оценки времени выполнения операций, необходимых для восстановления данных, оставшихся в процессорном кэше в результате спекулятивного выполнения инструкций CPU. Вторая часть производит определение раскладки памяти, используемой при размещении массива JavaScript.
Третья часть непосредственно выполняет эксплуатацию уязвимости Spectre (https://www.opennet.ru/keywords/spectre.html) для определения содержимого памяти текущего процесса в результате создания условий для спекулятивного выполнения определённых операций, результат которых отбрасывается процессором после определения неудачного прогноза, но следы выполнения оседают в общем кэше и могут быть восстановлены при помощи методов определения содержимого кэша по сторонним каналам, анализирующих изменение времени доступа к прокэшированным и не прокэшированным данным.
Предложенная техника эксплуатации позволяет обойтись без высокоточных таймеров, доступных через API performance.now() (https://developer.mozilla.org/en-US/docs/Web/API/Performance/now), и без поддержки типа SharedArrayBuffer (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer), позволяющего создавать массивы в разделяемой памяти. Эксплоит включает в себя гаджет Spectre, вызывающий контролируемое спекулятивное выполнение кода, и анализатор утечки по сторонним каналам, определяющий попавшие в кэш данные, полученные в ходе спекулятивного выполнения.
Гаджет реализован при помощи массива JavaScript, в котором предпринимается попытка доступа к области вне границ буфера, влияющая на состояние блока предсказания переходов из-за наличия добавленной компилятором проверки размера буфера (процессор забегая вперёд спекулятивно выполняет обращение, но откатывает состояние после проверки). Для анализа содержимого кэша в условиях недостаточной точности таймера предложен метод (https://leaky.page/plru.html), обманывающий применяемую в процессорах стратегию вытеснения данных из кэша Tree-PLRU (https://en.wikipedia.org/wiki/Pseudo-LRU#Tree-PLRU) и позволяющий за счёт увеличения числа циклов значительно увеличить разницу во времени при отдаче значения из кэша и при отсутствии значения в кэше.
Отмечается, что компания Google опубликовала прототип эксплоита для того чтобы показать реалистичность атак с использованием уязвимостей класса Spectre и для стимулирования web-разработчиков для применения техник, минимизирующих риски от подобных атак. При этом Google считает, что без существенной переработки предложенного прототипа невозможно создать универсальные эксплоиты, готовые не только для демонстрации, но и для повсеместного применения.
Для снижения риска владельцам сайтов предлагается (https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html) использовать реализованные в последнее время заголовки Cross-Origin Opener Policy (COOP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy)), Cross-Origin Embedder Policy (COEP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy)), Cross-Origin Resource Policy (CORP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy)), Fetch Metadata Request (https://developer.mozilla.org/en-US/docs/Glossary/Fetch_metadata_request_header), X-Frame-Options (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options), X-Content-Type-Options (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options) и SameSite Cookie (https://web.dev/samesite-cookies-explained/). Указанные механизмы напрямую не защищают от атак, но позволяют изолировать данные сайта от утечки (https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md#introduction) в процессы, в которых может быть выполнен JavaScript-код атакующего (утечка происходит из памяти текущего процесса, в котором помимо кода атакующего могут обрабатываться и данные другого сайта, открытого в той же вкладке). Основная идея в том, чтобы разделить в разных процессах выполнение кода сайта от стороннего кода, получаемого из ненадёжных источников, например, включаемого через iframe.
13.03.2021
https://www.opennet.ru/opennews/art.shtml?num=54751