Ограничитель Postgres, который дал трещину

Провайдеры управляемых PostgreSQL, такие как Supabase, Neon и Amazon Aurora, предоставляют клиентам мощные административные роли, но ограничивают доступ к настоящим привилегиям superuser. Их цель — обеспечить безопасную мультиарендную среду, где пользователи управляют своей базой данных, не влияя на базовый хост или других клиентов.

Провайдеры достигают этого путем развертывания пользовательских расширений или хуков. Эти уровни перехватывают и блокируют потенциально опасные операции — особенно те, что связаны с файловой системой — даже для самых высоких ролей, доступных клиентам. Например, провайдер может заблокировать lo_export, встроенную функцию PostgreSQL, предназначенную для записи больших объектов на диск сервера.

Однако этот уровень пользовательских ограничений может создать ложное чувство безопасности. Если ограничитель проверяет только имя команды, а не ее базовую функциональность, пользователь может обойти блокировку. Повторная регистрация того же внутреннего псевдонима функции C под новым, неконтролируемым именем позволяет обойти черный список, открывая доступ к функциональности, которая в противном случае была бы ограничена. Это фундаментальное упущение легло в основу значительной уязвимости.

Сообщенный обход использовал критическое «слепое пятно» в фильтрации по именам. Функция lo_export в PostgreSQL записывает большие объекты базы данных напрямую в файлы сервера. Управляемые провайдеры, осознавая эту опасность, обычно блокируют lo_export по имени, предотвращая ее выполнение даже для мощных клиентских ролей.

Исследователь безопасности продемонстрировал, как обойти этот ограничитель. Он воссоздал доступ к базовой внутренней процедуре, используя механизм LANGUAGE internal в PostgreSQL. Это позволило ему определить новую функцию с неконтролируемым именем, которая указывала на ту же самую внутреннюю реализацию C, что и заблокированная lo_export.

Эта техника эффективно клонировала опасную возможность под другим ярлыком, обходя расширение безопасности провайдера. Как только эта функция-псевдоним стала доступна, исследователь смог записывать произвольные файлы на диск сервера базы данных.

Эта уязвимость подчеркивает фундаментальную слабость моделей безопасности, полагающихся исключительно на фильтрацию по именам. Альтернативные имена могут указывать на одну и ту же базовую реализацию, а это означает, что проверка только ярлыка не эквивалентна контролю над возможностью. Расширения провайдеров блокировали слово "lo_export", но не действие по записи файлов на сервер, оставляя критический недостаток проектирования открытым.

Реплицированная функция lo_export, работающая теперь под незаблокированным псевдонимом, предоставила критический примитив: возможность записи произвольных файлов на хост PostgreSQL. Злоумышленники использовали это, чтобы поместить скомпилированную общую библиотеку (файл .so) на диск сервера.

После размещения вредоносной библиотеки следующим шагом стала ее регистрация в качестве функции PostgreSQL на языке C. Это достигается с помощью CREATE FUNCTION ... LANGUAGE C, что дает команду PostgreSQL загрузить и предоставить доступ к определенной функции из общей библиотеки непосредственно в SQL-среду базы данных.

Когда злоумышленник вызывал эту вновь зарегистрированную функцию на языке C с помощью простого SQL-запроса, база данных выполняла его произвольный код. Важно отметить, что этот код выполнялся с правами операционной системы самого процесса PostgreSQL на хосте базы данных. Это не является доступом root и не предоставляет автоматического доступа к данным других клиентов, так как экземпляры обычно изолированы.

Тем не менее, выполнение кода на хосте обеспечивает значительный плацдарм. Это позволяет обеспечить устойчивость (persistence) на сервере, дает возможность для всестороннего перечисления системных ресурсов и может облегчить попытки горизонтального перемещения (lateral movement) внутри инфраструктуры провайдера. Серьезность зависит от конкретных механизмов изоляции и сетевых конфигураций каждой управляемой службы. Подробный технический разбор см. в статье Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions.

Supabase отреагировала быстро, сообщив об исправлении четырех критических уязвимостей. Другие провайдеры ответили медленнее или дали нечеткие публичные комментарии, в то время как основная команда PostgreSQL возложила ответственность непосредственно на поставщиков услуг, заявив, что модель безопасности PostgreSQL предполагает, что superuser контролирует внутренние функции.

Читателям, желающим получить более глубокое понимание, следует ознакомиться с фундаментальным исследованием Мехмета Инсе (Mehmet Ince) «Breaking the PostgreSQL Superuser Guardrails». Проект supautils также является важным справочным материалом, наряду с подробной документацией Supabase по ролям и неподдерживаемым операциям, которые теперь учитывают эти уроки.

Этот инцидент стал суровым уроком для провайдеров. Блокировка опасных операций по имени оказалась недостаточной. Надежная безопасность требует: - строгого контроля над внутренними привязками и привязками к языку C - тщательных разрешений в каталоге - более сильной изоляции на уровне ОС

Эти меры, а не просто расширение черных списков, необходимы для обеспечения безопасности управляемой границы, которую они продают. Целостность облачного PostgreSQL зависит от того, насколько провайдеры соблюдают обещанные ими границы.

В чем заключалась уязвимость управляемого PostgreSQL?

Исследователь обошел ограничения провайдера, зарегистрировав опасную внутреннюю функцию PostgreSQL под именем, которое не блокировалось фильтрами провайдеров.

Раскрывала ли эта уязвимость содержимое баз данных других клиентов?

Не автоматически. Продемонстрированное повышение привилегий обеспечило выполнение кода от имени пользователя операционной системы PostgreSQL на хосте базы данных, создав плацдарм, а не мгновенный доступ к данным других арендаторов.

Была ли это уязвимость ядра PostgreSQL?

Команда безопасности PostgreSQL охарактеризовала это как проблему на стороне провайдера: управляемые службы должны безопасно обеспечивать соблюдение ограничений привилегий, которые они налагают.

Что должны изменить провайдеры управляемого PostgreSQL?

Им следует ограничить опасные привязки внутренних функций и функций на языке C, ужесточить разрешения в каталоге и изолировать процессы базы данных на уровне операционной системы.