Google закрыла в Chrome две 0-day, показанные на Pwn2Own 2024

Google закрыла в Chrome две 0-day, показанные на Pwn2Own 2024

Google закрыла в Chrome две 0-day, показанные на Pwn2Own 2024

Google оперативно устранила в Chrome две уязвимости нулевого дня (0-day), которые исследователи показали в ходе соревнования Pwn2Own 2024. Помимо этого, разработчики закрыли ещё пять дыр в браузере.

Одна из 0-day получила идентификатор CVE-2024-2887 и высокую степень риска. Класс этой бреши — несоответствие используемых типов данных (type confusion) в стандарте WebAssembly (Wasm).

На эту уязвимость указал Манфред Пол в первый день состязания Pwn2Own 2024, проходившего в Ванкувере. Эксперт также «пробил» и другие браузеры: Safari и Edge.

Вторую 0-day нашли исследователи из KAIST Hacking Lab. Её отслеживают под идентификатором CVE-2024-2886 (ошибка использования динамической памяти — use-after-free). Брешь затрагивает API WebCodecs, предназначенный для кодирования и декодирования аудио- и видеоконтента.

Сынхён Ли из KAIST Hacking Lab продемонстрировал удалённое выполнение кода на устройстве целевого пользователя с помощью эксплойта для CVE-2024-2886.

С выходом Google Chrome версий 123.0.6312.86/.87 (для Windows, macOS) и 123.0.6312.86 (для Linux) разработчики устранили перечисленные проблемы.

Напомним, на днях Mozilla тоже закрыла две 0-day в Firefox, показанные на Pwn2Own 2024. Девелоперы браузеров отработали качественно и оперативно, что не может не радовать.

Подпишитесь на новости

Claude Code удалил 116 ГБ и сообщил, что файлы выглядят нормально

Пользователь Windows сообщил, что Claude Code при уборке временных файлов удалил около 116 ГБ данных из его домашней директории. Затем агент заверил, что остановил команду и все выглядит целым. По описанию инцидента, удаление продолжалось еще примерно 50 минут.

В отчете на GitHub пользователь рассказывает, что работал над анализом для соревнования Kaggle.

Основная сессия запустила субагента, который решил очистить собственные временные файлы, но сформировал лишнюю команду рекурсивного удаления.

Целью стала домашняя директория, указанная коротким именем Windows формата 8.3. Автор предполагает, что защитная проверка могла не распознать такой вариант пути. Точный механизм отказа защиты и режим разрешений остаются неизвестными.

Через 120 секунд задача автоматически перешла в фон. Агент запросил остановку и получил сообщение об успехе, однако, судя по описанным изменениям файловой системы, удаление продолжалось. Вероятное объяснение — дочерний процесс пережил остановку задачи.

Проверка тоже оказалась поверхностной: агент посмотрел на названия папок верхнего уровня, которые могли сохраняться, пока их содержимое исчезало.

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

Особенно неприятна в этой истории уверенность агента. Наличие папки еще не означает наличие файлов.

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