Цепочка повышения привилегий в Snowflake Postgres доводит аккаунт без прав суперпользователя до выполнения команд в операционной системе сервера. Набор приёмов нашли в Varonis Threat Labs, а Snowflake закрыла проблему на своей стороне до публикации. Клиентам управляемого сервиса дополнительные действия не нужны. Сам приём важен для всех, кто рассчитывает на встроенные ограничения облачных баз данных.
Цепочка повышения привилегий в управляемом PostgreSQL Snowflake
Первый отчёт Varonis передала в Snowflake 31 мая 2026 года. Компания подтвердила получение 1 июня, а 9 июня признала, что локальное выполнение кода внутри виртуальной машины Snowflake Postgres пересекает границу безопасности сервиса. Публично цепочку показали 17 октября на конференции BSides NYC в Cloud Village. Сведений об эксплуатации в реальных атаках нет. Исследователи работали в своём тестовом окружении с одним арендатором, и отчёт не сообщает о доступе к данным клиентов.
Началом цепочки стала служебная учётная запись без прав суперпользователя. Её ключевой привилегией была CREATEROLE, то есть право создавать роли и управлять ими. Сама по себе эта привилегия не даёт полного контроля над базой. Здесь она открыла путь через механизмы, которым база доверяет. Сначала исследователи выдали аккаунту две встроенные роли с широким доступом к таблицам и системным каталогам. Затем полученный доступ позволил изменить записи в pg_cron, расширении, которое запускает задания по расписанию. Задание перенастроили так, чтобы оно выполнялось от привилегированного аккаунта postgres и создавало функцию SECURITY DEFINER. Такая функция работает с правами владельца, а не вызывающего пользователя. Через неё исследователи получили права суперпользователя PostgreSQL в обход прямого изменения ролей, которое Snowflake заблокировала.
До контроля над сервером оставался шаг. Snowflake закрыла привычные маршруты: команды чтения серверных файлов, изменения системных настроек и запуска программ через SQL. Исследователи нашли обход. Внутренний язык PostgreSQL позволяет привязать новое имя функции к C-функции, уже присутствующей в серверном программном обеспечении. Так вернулся доступ к заблокированным функциям чтения и записи файлов, только под другими именами. С доступом к файлам команда задействовала механизм больших объектов и записала данные в конфигурационный файл. Изменённым параметром стал archive_command. Это настройка, которая запускает команду оболочки при архивации заполненного сегмента журнала предзаписи (WAL, журнал изменений базы до их записи в файлы данных). Когда команда сработала, исследователи получили выполнение команд в операционной системе от системного аккаунта postgres.
Практический риск связан с последствиями такого доступа. Злоумышленник с похожими возможностями может изменить или уничтожить файлы базы, помешать восстановлению и отредактировать локальные журналы. Активность на уровне операционной системы не проходит через обычные SQL-запросы, поэтому записи аудита базы не покажут полную картину.
Похожие цепочки уже встречались. Varonis ранее показала удалённое выполнение кода в PostgreSQL через расширения PL/Perl и PL/Rust в AWS RDS, а также в Azure Cosmos for PostgreSQL. Отдельно известны ошибка выполнения кода в PostgreSQL и ошибка с командами оболочки в pgAdmin. Сами исследователи называют повышение привилегий в управляемом PostgreSQL системной закономерностью, а не единичной оплошностью одного провайдера.
Для команд, которые обслуживают собственные серверы PostgreSQL, выводы Varonis дают конкретные шаги. Привилегию CREATEROLE стоит считать высокорисковой и снимать с прикладных аккаунтов, если она не нужна. Полезно проверить выдачи ролей, задания pg_cron и функции SECURITY DEFINER на неожиданные изменения. Создание внутренних и C-функций лучше ограничить узким кругом лиц. Конфигурационные файлы требуют защиты прав доступа, а сама служба базы - сетевой изоляции от лишних подключений.
Блокировка известных способов выйти из SQL в операционную систему не решает задачу целиком. Пока рядом остаются смежные возможности, они складываются в обходной маршрут. В управляемом сервисе провайдер отвечает за сервер и его операционную систему, но распределение ролей внутри базы по-прежнему остаётся за клиентом.
Ссылки
