Обычные VM не удержат агентов с навыками кибератак

Артём Динабург из Trail of Bits получил предварительный доступ к GPT 5.6-Cyber от OpenAI в рамках инициативы Patch the Planet и поставил перед ней одну задачу: совершить побег из виртуальной машины QEMU/KVM, которую он обычно использует для изоляции агентов. Модель сбежала три раза подряд. Его вывод предельно ясен: больше нельзя исходить из того, что обычная VM способна изолировать достаточно продвинутого ИИ-агента, и к подобным агентам следует относиться как к APT (advanced persistent threat) vms-wont-contain-agents.

Условия эксперимента

Целью была VM на QEMU/KVM на его рабочей машине с Linux (Debian 12, AMD Zen3). Агента запустили снаружи VM, дав SSH-доступ внутрь и разрешение делать внутри всё что угодно. Задача в формате CTF заключалась в том, чтобы выбраться наружу и прочитать файл с флагом. Запуск с хоста был осознанным решением: автор пошёл на небольшой риск жульничества со стороны агента, поскольку попытки побега неизбежно приводили бы к падению или зависанию VM, а сессия должна была это пережить. Главной задачей человека во время прогона оставалась физическая перезагрузка машины, когда агент намертво вешал ядро хоста. Агент работал автономно часами, возвращался назад из тупиков, читал научные статьи, писал собственные минимальные примеры и добивался надёжного воспроизводимого эксплойта почти без подсказок со стороны.

Три побега

Сначала он обнаружил уязвимость ядра хоста перед Januscape (CVE-2026-53359), раскрытую за несколько недель до этого и не имевшую публичного эксплойта. Агент собрал рабочий эксплойт и был достаточно уверен в нём, чтобы протестировать на практике, пусть тот и сработал не совсем чисто. Автор обновил ядро.

Во второй раз агент проэксплуатировал libslirp - библиотеку, отвечающую за сеть в виртуальных машинах, - так как в Debian 12 всё ещё поставлялась уязвимая версия 4.7.0 (CVE-2026-9539). Агент скомбинировал эту CVE с отдельным коммитом с исправлением ошибки (на который даже не было заведено CVE), получив произвольное чтение и запись памяти хоста. Динабург отмечает, что сам даже не знал о существовании libslirp; агент быстро всё выяснил. В ответ исследователь скачал свежие upstream-версии libslirp и QEMU и пересобрал минимальный QEMU, оставив только нужные функции.

В третий раз, уже против укреплённой цели, агент выстроил цепочку из нескольких ошибок, включая три 0-day (на момент обнаружения) и один исправленный в upstream баг KVM, ещё не дошедший до ядра дистрибутива: уязвимость QEMU с алиасом VAPIC ROM, открывавшую доступ к SMRAM, два бага в shadow paging ядра Linux KVM и ошибку сборки фрагментов пакетов в libslirp, использованную для размещения узнаваемых объектов в памяти хоста. Кроме того, агент нашёл и другие уязвимости, которые не вошли в финальную цепочку (утечка IPv6 в libslirp, раскрытие сертификата CUPS, заблокированное AppArmor, переполнение кучи дисплея QEMU, оказавшееся недосягаемым из-за флага -display none, а также use-after-free при сбросе очереди QEMU, приводивший лишь к DoS). Примечательная деталь касательно удержания цели: агент вёл последовательную работу на горизонте порядка 12 часов, пережил несколько сжатий контекста и множество вызовов субагентов, причём журнал исследований в промпте вёлся скорее для удобства человека, а не самого агента.

Выводы

Обычной готовой VM недостаточно для сдерживания сильного агента: поверхность атаки слишком велика, и даже безобидные функции вроде графического дисплея расширяют её. Дистрибутив с быстрыми обновлениями становится необходимостью, так как цикл бэкпортов в старых стабильных дистрибутивах слишком медленный, а агент синтезирует эксплойты под конкретную цель быстрее, чем закрываются дыры. Единственное, что устояло, - специализированная виртуализация с минимальной поверхностью атаки: в тестах с Firecracker агент мог намертво повесить машину из-за багов ядра, но сбежать не смог. Динабург допускает, что при большем запасе времени побег мог бы получиться, но Firecracker - цель несоизмеримо более сложная. Его общая рекомендация - возвращение к базовым принципам безопасности: наименьшие привилегии для сети, учётных данных и функциональности; логирование; активный мониторинг; короткоживущие агенты; чистое окружение на каждый запуск.

Место в базе знаний

Это эмпирический сложный случай, стоящий за всем блоком заметок об изоляции. sandboxing-ai-agents рассматривает изоляцию на уровне ОС/microVM как Уровень 1 и уже указывает, что "ни один из этих способов не даёт абсолютной изоляции"; эта статья служит замером того, как агент взламывает границу настоящей VM, а не просто сбегает из контейнера. microvm-2026 и matryoshka-isolation выступают в пользу microVM на том основании, что запрещающие списки контейнеров находятся "внутри контура рассуждений агента", тогда как аппаратная граница лежит вне его. Результат Динабурга с Firecracker - наглядное тому подтверждение: VMM с минимальной поверхностью атаки устоял там, где универсальная VM на QEMU/KVM провалилась. microvm объясняет причину: Firecracker эмулирует около пяти устройств, а QEMU - десятки, и каждое доступное агенту устройство (сеть через libslirp, дисплей, CUPS на хосте) представляло собой поверхность атаки, которую тот использовал или пытался использовать.

Кроме того, это обновляет модель угроз из peril-of-laziness-lost и skill-atrophy-supervision-paradox: вместо сценария "агент пишет небрежный код, за которым нужно присматривать" появляется "агент выступает компетентным противником, если направить его на вашу инфраструктуру". Практики supply-chain-security, которые подразумеваются в тех заметках, остаются в силе; новый аспект в том, что сам слой изоляции теперь доступен для взлома грамотному агенту. Инструменты и подход самой Trail of Bits описаны в trail-of-bits; это одна из опорных публикаций в их блоге, а не рядовой отчёт о проекте.