Атака через JavaScript по определению содержимого L3-кэша CPU

Атака через JavaScript по определению содержимого L3-кэша CPU

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

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

Потенциально атаке подвержены все системы на базе относительно новых моделей процессоров Intel (Ivy Bridge, Sandy Bridge и Haswell), на которых используются актуальные выпуски браузеров c поддержкой HTML5. Так как L3-кэш общий для всех ядер CPU и совместно используется всеми процессами в системе, включая ядро, через периодический мониторинг содержимого кэша атакующий может получить детальные сведения о пользователях и системе, сообщает opennet.ru.

Предложенный метод является разновидностью атак по сторонним каналам (side-channel attacks), использующим косвенные методы, такие как анализ перепадов напряжения, температуры и времени выполнения операции, для восстановления данных из изолированного окружения. В частности, в результате атаки пошагово моделируется содержимое кэша на основе измерения отклонения времени доступа к данным до и после сброса кэша. В атаке используется особенность работы JavaScript-движков с типизированными массивами, а именно применяемые методы маппинга адресов физической памяти в кэш. Для измерения времени используются средства JavaScript для доступа к системному таймеру с высоким разрешением с оглядкой на фиксированные задержки в JavaScript runtime. 

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

Cloudflare: сбой вызвал некорректный файл из-за ошибки в правах БД

Стали известны подробности сбоя у Cloudflare: система Bot Management сгенерировала некорректный файл конфигурации. Он оказался слишком большим — в нём неожиданно появилось более 200 параметров вместо привычных ~60. Это превысило встроенный лимит и вызвало падение программного модуля, через который проходит трафик Cloudflare.

Напомним, у Cloudflare во вторник случился самый серьёзный сбой с 2019 года. Из-за ошибки в конфигурации баз данных часть глобальной сети компании перестала корректно обрабатывать трафик почти на шесть часов.

В результате множество сайтов и сервисов по всему миру были недоступны или работали с перебоями.

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

Когда увеличенный файл начинал распространяться по инфраструктуре, модуль Bot Management, написанный на Rust, уходил в панику, вызывая массовые ошибки 5xx на сайтах.

Гендиректор Cloudflare Мэттью Принс подчеркнул, что речь не идёт о кибератаке:

«Проблема не была вызвана кибератакой или злонамеренной активностью. Всё началось с изменения прав одной из наших баз данных, что привело к генерации некорректного файла для системы Bot Management».

К 14:30 UTC инженеры вычислили причину и подменили проблемный файл на предыдущую корректную версию. Полностью все системы восстановили работу к 17:06 UTC. Сбой затронул CDN и сервисы безопасности, Turnstile, Workers KV, доступ к панели управления, почтовую защиту и механизмы аутентификации.

Принс назвал инцидент «неприемлемым»:

«Это был худший сбой Cloudflare с 2019 года… Мы приносим извинения клиентам и всему интернету. С учётом нашей роли в экосистеме любой простой недопустим».

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

RSS: Новости на портале Anti-Malware.ru