Vercel Sandbox выдержал взлом: 1285 отчётов, $242 000 и баг в ядре Linux

Vercel закрыла хакерский челлендж вокруг Vercel Sandbox, облачной среды для изолированного запуска кода. За две недели исследователи прислали 1285 отчётов, а Vercel выплатила $242 000 наград. Ни один отчёт не показал доступа к данным клиентов. При этом самая серьёзная находка оказалась не в коде Vercel, а в основе, на которой держится значительная часть облаков: в сетевом стеке ядра Linux обнаружили уязвимость нулевого дня.

Zero-day на третий день

Главный отчёт пришёл на третий день программы. Paulos Yibelo (pwn.ai), исследователь с HackerOne, работал из обычной песочницы без особых прав. Он нашёл дефект в сетевом стеке ядра Linux: специально сформированные пакеты, отправленные изнутри микро-ВМ, позволяли провести три разные атаки.

• Утечка памяти хоста по сети. Память машины, которую песочница делит с другими арендаторами, попадала в пакеты, уходящие гостем в интернет. Утечка шла непрерывно, пока гость продолжал отправлять трафик. Атаку показали на боевых песочницах Vercel.
• Обрушение хоста. Двух пакетов хватало, чтобы машина упала, а вместе с ней все песочницы, которые на ней работали.
• Выполнение кода на хосте. Тот же изъян давал возможность запускать команды с полными правами администратора и выйти за границу изоляции.

Обрушение и выполнение кода исследователь воспроизвёл на собственных машинах с KVM и Firecracker, повторяющих конфигурацию Vercel Sandbox.

Почти все крупные облачные провайдеры изолируют клиентов именно на этом слое ядра, поэтому речь о риске для общей инфраструктуры. Vercel говорит, что работала с исследователем, а также с AWS и другими партнёрами, чтобы ускорить исправление. Параллельно Yibelo связался с мейнтейнерами ядра и подготовил с ними кандидаты в патчи. Они проходят закрытую проверку, CVE пока не присвоены, подробности не раскрываются. О самом факте уязвимости компания сообщила потому, что о ней уже заговорили публично.

Взгляд изнутри: стажёр и Trail of Bits

Помимо публичной охоты за баунти, Vercel провела внутренние проверки с полным доступом к исходникам и привлекла Trail of Bits. Не все находки пришли снаружи. Стажёр Vercel Marcos Hernanz обнаружил межарендную утечку в слое хранения данных Linux device-mapper: любая песочница могла читать переиспользованные дисковые блоки ранее удалённых песочниц.

Trail of Bits потратила четыре инженеро-недели, выделив двух специалистов. У них был полный доступ к репозиториям и два корпоративных тестовых контура. Итог: 20 находок, каждую протестировали, подтвердили и привязали к конкретному месту в коде. Архитектурный обзор показал, что граница виртуализации надёжна. Каждая песочница работает в отдельной микро-ВМ Firecracker с собственным гостевым ядром, модель устройств намеренно минимальна, и ни один гость не делит работающее ядро ни с хостом, ни с другим арендатором.

Три структурных вывода

Аудиторы дали три рекомендации, и Vercel утверждает, что все их выполнила.

• Убрать доверие к гостю. Управляющий слой принимал значения, возвращаемые ПО внутри микро-ВМ, а любое такое значение по сути вводится арендатором. Всё, что пересекает границу, теперь вычисляется на стороне сервера или подписывается ключом, недоступным гостю.
• Одна политика, один арбитр. Контроль исходящего трафика был размазан по подсистемам, каждая из которых разбирала сетевую политику самостоятельно, и их решения не всегда совпадали. Теперь на каждый тип данных одна процедура канонизации, на каждое решение один компонент, а соединения перепроверяются при смене политики.
• Исходить из того, что появится следующий zero-day. Защиту вокруг каждой песочницы усилили, чтобы ограничить ущерб при взломе ПО виртуализации. Ядра хостов обновляются, вложенная виртуализация отключена, а jailer от Firecracker запускает каждый процесс микро-ВМ с урезанными правами.

Практические выводы для тех, кто запускает чужой код

Песочницы для ИИ-агентов и сгенерированного кода становятся стандартной частью стека, и этот случай показывает, где реально проходит риск. Микро-ВМ с отдельным ядром сработала: даже при уязвимости в хосте клиентских данных никто не достал. Но изоляция не отменяет необходимости обновлять хостовые ядра и не доверять ничему, что вернулось из гостя.

Командам, которые строят собственные песочницы или выбирают провайдера, стоит проверить три вещи: не принимает ли управляющий слой данные от гостя без проверки, не дублируется ли разбор сетевых политик в разных компонентах, и как быстро провайдер выкатывает патчи ядра. Подробности по CVE появятся после публикации исправлений, и тогда понадобится сверить свои версии ядра и конфигурации Firecracker.