Брешь в Zen 5 угрожает криптозащите процессоров AMD Ryzen и Epyc

Брешь в Zen 5 угрожает криптозащите процессоров AMD Ryzen и Epyc

Брешь в Zen 5 угрожает криптозащите процессоров AMD Ryzen и Epyc

Как сообщила AMD, разработчики скоро выпустят обновление микрокода для устранения уязвимости, способной ослабить криптографическую защиту в процессорах Ryzen и Epyc. Ошибка получила идентификатор CVE-2025-62626 и 7,2 балла по шкале CVSS, что соответствует уровню «высокая степень риска».

Проблема затрагивает процессоры архитектуры Zen 5 и связана с работой функции RDSEED, которая отвечает за генерацию случайных чисел — важный элемент при создании криптографических ключей.

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

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

В AMD уточнили, пока компания работает над патчем пользователи могут воспользоваться обходными решениями. Например, использовать 64-битную версию RDSEED, в которой нет уязвимости, или отключить обнаружение функции RDSEED в системе с помощью параметра clearcpuid=rdseed при загрузке, либо флага -rdseed в настройках виртуальных машин QEMU.

Первые патчи уже выпущены для серверных процессоров Epyc 9005 (TurinPI 1.0.0.8) — они стали доступны 28 октября. Однако некоторые пользователи Linux сообщили о проблемах с последним апдейтом ядра 6.18-rc4, которое также включает попытку устранить баг: по словам разработчика CachyOS, оно мешает части пользователей войти в графический интерфейс.

Для остальных серий патчи появятся позже. Обновления для Ryzen и Epyc Embedded 9005 ожидаются до конца ноября, а для Epyc Embedded 4005 и Ryzen Embedded 9000 — в январе.

Удалили Google API-ключ? Плохие новости: он может жить ещё 23 минуты

Исследователи из Aikido обнаружили неприятную особенность Google API-ключей: после удаления они могут продолжать работать до 23 минут. Сценарий простой. Ключ утёк, разработчик в панике бежит его удалять, выдыхает — вроде всё, опасность миновала. Но нет.

По данным Aikido, удаление ключа распространяется по инфраструктуре Google не мгновенно: одни серверы начинают отклонять запросы почти сразу, другие продолжают принимать их ещё десятки минут.

В тестах исследователи создавали API-ключ, удаляли его и затем отправляли по 3-5 авторизованных запросов в секунду, пока ответы не переставали проходить. Среднее окно составляло около 16 минут, максимум — почти 23 минуты. В отдельные минуты более 90% запросов всё ещё успешно проходили.

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

Проблема особенно болезненна на фоне новой биллинговой политики Google. Как пишет The Register, у некоторых пользователей лимиты расходов могут автоматически подниматься: например, с 250 до 100 тыс. долларов, если аккаунт старше 30 дней и уже потратил больше 1 тыс. долларов за всё время.

СМИ уже писали о случаях, когда украденные Google API-ключи приводили к пятизначным счетам за считаные минуты. В трёх известных случаях Google вернула разработчикам в общей сложности 154 тыс. долларов, но это, мягко говоря, не тот пользовательский опыт, который хочется повторять.

Самое весёлое — Google, по словам Aikido, не планирует исправлять 23-минутное окно. Компания закрыла отчёт как «Won’t Fix», объяснив, что задержка из-за распространения удаления ключей работает как задумано. Отличная формулировка; ключ уже удалён, деньги ещё списываются, всё по плану.

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