В августе мы запустили хакерский конкурс с призовым фондом $1 млн для Vercel Sandbox, предложив исследователям безопасности попытаться взломать Vercel Sandbox. Мы также договорились с экспертами по кибербезопасности из Trail of Bits о проведении аудита исходного кода и архитектуры безопасности.
Вот краткий итог конкурса:
- 1285 отчетов за две недели
1285 отчетов за две недели
- Выплачено $242 000 в виде вознаграждений
Выплачено $242 000 в виде вознаграждений
- Обнаружена одна уязвимость нулевого дня в ядре Linux
Обнаружена одна уязвимость нулевого дня в ядре Linux
Ни один из отчетов не показал, что кто-либо получил доступ к данным клиентов в Vercel Sandbox. Самой серьезной находкой стал дефект в апстрим-ядре Linux.
Скопировать ссылку на заголовок Уязвимость нулевого дня в ядре
Самый важный отчет программы поступил на третий день.
Paulos Yibelo (pwn.ai), исследователь HackerOne, работавший из стандартной «песочницы» без специальных прав доступа, обнаружил дефект в сетевом стеке ядра Linux. Паулос выяснил, что специально сформированные пакеты, отправленные изнутри microVM, позволяют провести три различных типа атак:
- Утечка памяти хоста через сеть
Утечка памяти хоста через сеть
- Аварийное завершение работы хост-машины
Аварийное завершение работы хост-машины
- Выполнение кода на хосте
Выполнение кода на хосте
Скопировать ссылку на заголовок Утечка памяти хоста
В ходе первой атаки память хоста — машины, которую ваша «песочница» делит с другими арендаторами, — попадает в пакеты, которые гостевая система отправляет через интернет. Это может происходить непрерывно, пока гостевая система продолжает отправку.
Эта атака была продемонстрирована на производственных «песочницах» Vercel.
Скопировать ссылку на заголовок Аварийное завершение работы хоста и выполнение кода на хосте
Исследователь также обнаружил, что путем отправки определенных пакетов можно скомпрометировать хост.
Во-первых, отправив два пакета, исследователь вызвал сбой хост-машины, что привело к отключению всех запущенных на ней «песочниц». Во-вторых, используя тот же изъян, он смог выполнять команды с полными правами администратора на хосте, выйдя за пределы изоляции «песочницы».
Атаки, связанные с аварийным завершением работы через пакеты и выполнением кода на хосте, были продемонстрированы на собственных машинах KVM и Firecracker исследователя, соответствующих конфигурации Vercel Sandbox.
Скопировать ссылку на заголовок Ответственное раскрытие уязвимости ядра
Почти каждый крупный облачный провайдер изолирует рабочие нагрузки клиентов на этом же уровне ядра Linux, поэтому любой дефект представляет собой риск для общей инфраструктуры.
Сразу после получения уведомления мы начали сотрудничать с исследователем, чтобы понять и устранить уязвимость, работая с AWS и другими отраслевыми партнерами для приоритизации исправления и обеспечения безопасности клиентов Vercel и других разработчиков, использующих это ядро.
Исследователь также связался с мейнтейнерами ядра и работал с ними над созданием патчей. Исправления находятся на закрытом рассмотрении, а идентификаторы CVE ожидаются, поэтому мы не публикуем дополнительные подробности, пока патчи не станут общедоступными. Мы раскрываем факт существования уязвимости, поскольку она была отдельно раскрыта публично.
Скопировать ссылку на заголовок Наш подход к стресс-тестированию Vercel Sandbox
Конкурс на HackerOne сделал вознаграждения доступными для любого исследователя, но мы также расширили нашу программу, включив в нее внутренние оценки и независимое расследование.
Перед запуском публичной программы вознаграждений мы провели внутренние проверки безопасности с полным доступом к исходному коду и поддержкой инженеров, которые создали и поддерживают Vercel Sandbox. Мы также привлекли Trail of Bits, пригласив двух инженеров для оценки нашей архитектуры безопасности.
Не все находки были сделаны извне. Маркос Эрнандес, стажер Vercel, обнаружил утечку данных между арендаторами в уровне хранения device-mapper ядра Linux. Эта уязвимость позволяла любой «песочнице» считывать повторно используемые блоки диска из ранее удаленных «песочниц».
Скопировать ссылку на заголовок Глубокий анализ (White-box)
Специалисты Trail of Bits провели четыре инженерные недели внутри нашего исходного кода, имея полный доступ к репозиториям и двум корпоративным тестовым командам. Они предоставили 20 находок, каждая из которых была протестирована, подтверждена и соотнесена с конкретным кодом.
Они также провели архитектурный обзор и пришли к выводу, что наш контур виртуализации надежен. Каждая «песочница» работает в своей собственной microVM Firecracker с выделенным гостевым ядром, а модель устройства намеренно минимизирована. Ни один гость не использует общее запущенное ядро с хостом или другим арендатором.
В дополнение к этому фундаменту они дали нам три структурные рекомендации, которые мы внедрили:
- Найти и исключить любое доверие к гостевой системе. Наша плоскость управления принимала значения, возвращаемые программным обеспечением, работающим внутри microVM, а каждое из этих значений является вводом арендатора. Все, что пересекает границу, должно быть получено на стороне сервера или подписано ключом, к которому гость не имеет доступа.
Найти и исключить любое доверие к гостевой системе. Наша плоскость управления принимала значения, возвращаемые программным обеспечением, работающим внутри microVM, а каждое из этих значений является вводом арендатора. Все, что пересекает границу, должно быть получено на стороне сервера или подписано ключом, к которому гость не имеет доступа.
- Одна политика, один решающий орган. Принудительное применение исходящего трафика было разделено между подсистемами, каждая из которых независимо анализировала одну и ту же сетевую политику, и они не всегда были согласны друг с другом. Теперь мы используем одну процедуру канонизации для каждого типа данных, один компонент для принятия решений и повторно проверяем соединения при изменении политики.
Одна политика, один решающий орган. Принудительное применение исходящего трафика было разделено между подсистемами, каждая из которых независимо анализировала одну и ту же сетевую политику, и они не всегда были согласны друг с другом. Теперь мы используем одну процедуру канонизации для каждого типа данных, один компонент для принятия решений и повторно проверяем соединения при изменении политики.
- Предполагать следующую уязвимость нулевого дня. Мы усилили защиту вокруг каждой «песочницы», чтобы ограничить ущерб, если злоумышленник воспользуется программным обеспечением для виртуализации. Мы поддерживаем ядра хостов в актуальном состоянии, отключили вложенную виртуализацию и используем jailer от Firecracker для запуска каждого процесса microVM с ограниченными правами, изолируя его от остальной части хоста.
Предполагать следующую уязвимость нулевого дня. Мы усилили защиту вокруг каждой «песочницы», чтобы ограничить ущерб, если злоумышленник воспользуется программным обеспечением для виртуализации. Мы поддерживаем ядра хостов в актуальном состоянии, отключили вложенную виртуализацию и используем jailer от Firecracker для запуска каждого процесса microVM с ограниченными правами, изолируя его от остальной части хоста.
Скопировать ссылку на заголовок Результаты Vercel Sandbox
Мы получили 1285 отчетов за две недели. Такой объем возможен только потому, что исследователи теперь охотятся со скоростью ИИ.
Вот разбивка отчетов по категориям:
- 877 дубликатов
877 дубликатов
- 319 неприменимых
319 неприменимых
- 57 действительных
57 действительных
- 32 информативных
32 информативных
В ходе сортировки отчетов мы подтвердили:
- 1 критическая находка
1 критическая находка
- 5 находок высокого уровня
5 находок высокого уровня
- 9 находок среднего уровня
9 находок среднего уровня
- 42 находки низкого уровня
42 находки низкого уровня
- 32 информативные находки
32 информативные находки
Мы выплатили $242 000 в виде вознаграждений за ошибки.
Находки среднего, низкого и информативного уровней представляют собой небольшие пробелы в границах политик, такие как правило брандмауэра, которое вело себя иначе, чем было задокументировано, и поле, которое доверяло гостю больше, чем следовало.
Наиболее серьезной находкой стал дефект нулевого дня в ядре Linux, при этом ни в одном отчете не было указано, что кто-либо читал файлы, секреты или данные приложений клиентов.
Больше всего нас впечатлила неоднородность отчетов. Было очевидно, что исследователи использовали разные настройки и имеют разные области интересов. Некоторые явно разбираются в пространствах имен Linux и направили своих агентов прямо на границу ядра. Другие занялись сетевыми политиками, а многие обратили внимание на области, которые мы даже не планировали включать в программу.
Именно такое разнообразие вы и финансируете с помощью публичного конкурса. Вот один из наиболее интересных результатов, полученных в ходе него.
Скопировать ссылку на заголовок Восстановление снимка диска между арендаторами (с ограничениями)
Этот отчет, поданный в первый же день конкурса, является нашим любимым примером того, почему мы проводим публичную программу bug bounty даже после внутренних оценок и тестирования методом «белого ящика».
Когда вы делаете снимок «песочницы» (sandbox), плоскость управления должна записать, где оказались данные снимка: {storage_url, size, checksum}. Уязвимость, которую обнаружил исследователь, была тонкой: этот ответ поступал от программного обеспечения, работающего внутри гостевой системы, а службы, работающие на хосте, доверяли ему. Это нарушение границы доверия. Гостевая система — это место, где наши клиенты (и хакеры) запускают недоверенный код, поэтому хост никогда не должен принимать его слова как авторитетные.
Исследователь объединил известный, задокументированный примитив для выхода из контейнера с этой ошибкой доверия. Они перехватили ответ о снимке внутри своей собственной «песочницы» и переписали его, поменяв местами объекты хранения двух снимков, принадлежащих двум разным учетным записям, которыми они владели. Это означало, что при восстановлении «вашего» снимка материализовывалась вся файловая система другой учетной записи.
Исследователь продемонстрировал, что каждая учетная запись может читать и изменять файлы другой, проверил результаты с помощью хешей и сохранил тестовые ресурсы, чтобы мы могли независимо воспроизвести полученные данные.
Ограничения этой атаки имеют значение. Чтобы направить подмену на конкретную жертву, нужно было знать внутренний ключ хранения снимка этой жертвы — случайный 96-битный идентификатор, который платформа генерирует для каждого снимка и никогда не раскрывает через API. Единственное место, где появляется этот ключ, — внутри «песочницы» самой жертвы. Исследователь владел обеими учетными записями, что и сделало доказательство возможным; не было продемонстрировано никакого пути для постороннего лица, чтобы нацелиться на другого арендатора. Мы все равно отнеслись к этому как к приоритетному исправлению, потому что граница, которая зависит от того, останется ли секрет секретом, не является границей.
Компания Trail of Bits независимо выявила ту же первопричину в ходе своей оценки, что подтвердило нам: находка реальна, важна и обнаруживаема с двух совершенно разных сторон.
Исправление было выпущено в течение недели, и теперь плоскость управления привязывает каждый объект снимка к проекту, который его создал, и отклоняет все остальное. Создание снимков было перенесено из среды, доступной гостю, в службу на стороне хоста, а пути хранения теперь ограничены рамками проекта с жестко проверяемыми URL-адресами.
Скопировать ссылку на заголовок Спасибо исследовательскому сообществу
Мы хотели бы поблагодарить каждого исследователя, который подал отчет, независимо от того, была ли его находка уязвимостью нулевого дня или дубликатом. Каждый метод, обнаруженный в ходе конкурса, помогает нам лучше защищать рабочие нагрузки, выполняемые в Vercel Sandbox.
Также спасибо Trail of Bits за всестороннее внутреннее расследование и руководство.
Ознакомьтесь с оригинальным анонсом конкурса и узнайте больше о Vercel Sandbox в документации.
