Из базы данных прямо в Linux. PostgreSQL позволила обойти защиту Snowflake штатными средствами
Облачный сервис может запретить опасные команды, но оставить обходной путь через обычные возможности базы данных. Команда Varonis Threat Labs обнаружила в Snowflake Postgres цепочку действий, позволявшую повысить привилегии и выполнять команды операционной системы на сервере PostgreSQL. Snowflake устранила проблему до публикации технического разбора.
Уязвимая цепочка начиналась с роли snowflake_admin, которая не имела статуса суперпользователя, но обладала правом CREATEROLE. Участники теста назначили себе системные роли pg_read_all_data и pg_write_all_data, получив доступ к чтению и изменению таблиц во всём экземпляре PostgreSQL. Для атаки требовались права в базе, одного сетевого доступа было недостаточно.
Следующим звеном стал планировщик pg_cron. Команда изменила служебную запись задания так, чтобы PostgreSQL запустила SQL-код от имени postgres через локальное соединение без проверки пароля. Задание создало функцию SECURITY DEFINER с правами суперпользователя и открыло путь к роли snowflake_superuser. Запрет на прямое назначение статуса суперпользователя не сработал.
Даже права суперпользователя не давали прямого доступа к операционной системе. Snowflake заранее заблокировала COPY TO PROGRAM, ALTER SYSTEM и функции чтения файлов. Однако через LANGUAGE internal удалось зарегистрировать новые SQL-функции, связанные с уже существующими внутренними функциями PostgreSQL. Так участники теста вернули чтение и запись файлов под другими именами.
Во время проверки команда прочитала системные файлы, внутренний сертификат mTLS с закрытым ключом и временные учётные данные AWS STS, хранившиеся открыто. Затем механизм lo_export позволил перезаписать postgresql.auto.conf и подменить параметр archive_command. PostgreSQL выполняет указанную команду через оболочку Linux при архивировании журнала WAL, фиксирующего изменения базы.
В результате команды выполнялись от системной учётной записи postgres внутри выделенной виртуальной машины. Доступ мог позволить менять или уничтожать файлы базы, мешать восстановлению и оставлять часть действий вне обычного аудита SQL. Демонстрация ограничилась собственным изолированным экземпляром, доступ к чужим клиентским средам не подтверждён.
Для PostgreSQL подобный переход от служебных прав к коду ОС уже не первый случай. В сентябре стало известно об уязвимости репликации, которая позволяла загрузить нативный код через логическое декодирование. Новый сценарий отличается тем, что использует цепочку штатных возможностей и обходит ограничения поставщика без прямого отключения защитных механизмов.
Varonis передала детали Snowflake 31 мая 2026 года. Компания подтвердила проблему 9 июня, а 17 октября результаты представили на BSides NYC. Исправления внесли на стороне сервиса до раскрытия, поэтому клиентам не нужны патчи. Varonis советует ограничивать привилегию CREATEROLE, не давать snowflake_admin прикладным сервисам и закрывать доступ к базам сетевыми правилами.