A Fronteira "Gerenciada" Não Era um Muro
Provedores de PostgreSQL gerenciado como Supabase, Neon e Amazon Aurora oferecem aos clientes funções administrativas poderosas, mas retêm privilégios reais de superuser. Eles visam entregar um ambiente seguro e multi-tenant onde os usuários controlam seu banco de dados sem impactar o host subjacente ou outros clientes.
Os provedores alcançam isso implantando extensões ou hooks personalizados. Essas camadas interceptam e bloqueiam operações potencialmente perigosas — especialmente aquelas que envolvem o sistema de arquivos — mesmo para as funções de cliente de nível mais alto. Por exemplo, um provedor pode bloquear lo_export, uma função nativa do PostgreSQL projetada para gravar objetos grandes no disco do servidor.
Essa camada de restrição personalizada, no entanto, pode criar uma falsa sensação de segurança. Se o guardrail verifica apenas o nome de um comando em vez de sua funcionalidade subjacente, um usuário pode contornar o bloqueio. Registrar novamente o mesmo alias de função C interna sob um novo nome não monitorado ignora a lista de bloqueio, permitindo a invocação de funcionalidades que deveriam estar restritas. Essa supervisão fundamental formou a base de uma vulnerabilidade significativa.
Um Novo Nome Passou pelo Filtro
O bypass relatado explorou um ponto cego crítico na filtragem baseada em nomes. A função lo_export do PostgreSQL grava objetos grandes do banco de dados diretamente nos arquivos do servidor. Provedores gerenciados, reconhecendo esse perigo, normalmente bloqueiam lo_export pelo nome, impedindo sua execução mesmo para funções de cliente poderosas.
Um pesquisador de segurança demonstrou como contornar esse guardrail. Eles recriaram o acesso à rotina interna subjacente usando o mecanismo LANGUAGE internal do PostgreSQL. Isso permitiu que eles definissem uma nova função com um nome não monitorado que apontava para a mesma implementação C de backend que a lo_export bloqueada.
Essa técnica clonou efetivamente a capacidade perigosa sob um rótulo diferente, contornando a extensão de segurança do provedor. Uma vez que essa função com alias estava disponível, o pesquisador pôde gravar arquivos arbitrários no disco do servidor do banco de dados.
Essa vulnerabilidade destaca uma fraqueza fundamental em modelos de segurança que dependem apenas de filtragem baseada em nomes. Nomes alternativos podem apontar para a mesma implementação subjacente, o que significa que verificar apenas o rótulo não é equivalente a controlar a capacidade. As extensões dos provedores bloquearam a palavra "lo_export", mas não a ação de gravar arquivos no servidor, deixando exposta uma falha de design crítica.
Da Permissão SQL ao Código em Nível de Host
A função lo_export replicada, agora operando sob um alias não bloqueado, forneceu uma primitiva crítica: a capacidade de gravar arquivos arbitrários no host do PostgreSQL. Os atacantes aproveitaram isso para depositar uma biblioteca compartilhada compilada (arquivo .so) no disco do servidor.
Com a biblioteca maliciosa no lugar, o próximo passo envolveu registrá-la como uma função de linguagem C do PostgreSQL. Isso é feito via CREATE FUNCTION ... LANGUAGE C, que instrui o PostgreSQL a carregar e expor uma função específica da biblioteca compartilhada diretamente no ambiente SQL do banco de dados.
Quando um atacante invocava essa função em linguagem C recém-registrada por meio de uma consulta SQL simples, o banco de dados executava seu código arbitrário. Crucialmente, esse código era executado com as permissões de sistema operacional do próprio processo PostgreSQL no host do banco de dados. Isso não é acesso root, nem concede automaticamente acesso aos dados de outros clientes, já que as instâncias são tipicamente isoladas.
No entanto, a execução no host fornece uma base significativa. Ela permite persistência no servidor, possibilita uma enumeração abrangente do sistema e pode facilitar tentativas de movimento lateral dentro da infraestrutura do provedor. A gravidade depende fortemente dos mecanismos de isolamento específicos e das configurações de rede de cada serviço gerenciado. Para uma análise técnica detalhada, veja Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions.
Gostando do artigo? Receba um assim na sua caixa de entrada toda manhã.
um e-mail por dia · cancele em dois cliques · sem rastreadores de terceiros
Provedores devem proteger a fronteira que vendem
O Supabase respondeu rapidamente, relatando patches para quatro problemas críticos. Outros provedores ofereceram respostas públicas mais lentas ou pouco claras, enquanto a equipe principal do PostgreSQL colocou a responsabilidade diretamente sobre os provedores de serviço, afirmando que o modelo de segurança do PostgreSQL assume que o superuser controla as funções internas.
Leitores que buscam uma visão mais profunda devem consultar a pesquisa fundamental de Mehmet Ince, “Breaking the PostgreSQL Superuser Guardrails”. O projeto supautils também fornece uma referência crítica, juntamente com a documentação detalhada do Supabase sobre funções e operações não suportadas, que agora refletem essas lições.
Este incidente oferece uma lição clara para os provedores. Bloquear operações perigosas por nome prova ser insuficiente. A segurança robusta exige - controles rigorosos sobre associações internas e em linguagem C - permissões de catálogo meticulosas - isolamento mais forte em nível de SO
Essas medidas, e não simplesmente listas de bloqueio mais longas, são essenciais para proteger a fronteira gerenciada que eles vendem. A integridade do PostgreSQL na nuvem depende de os provedores imporem as fronteiras que prometem.
Perguntas Frequentes
Qual foi a vulnerabilidade do PostgreSQL gerenciado?
Um pesquisador contornou as restrições do provedor registrando uma função interna perigosa do PostgreSQL sob um nome que os filtros dos provedores não bloqueavam.
A falha expôs o conteúdo do banco de dados de outros clientes?
Não automaticamente. A escalada demonstrada forneceu execução de código como o usuário do sistema operacional PostgreSQL no host do banco de dados, criando uma base em vez de acesso instantâneo aos dados de outros locatários.
Isso foi uma vulnerabilidade do núcleo do PostgreSQL?
A equipe de segurança do PostgreSQL caracterizou isso como um problema do lado do provedor: serviços gerenciados devem aplicar com segurança os limites de privilégio que impõem.
O que os provedores de PostgreSQL gerenciado devem mudar?
Eles devem restringir associações perigosas de funções internas e em linguagem C, fortalecer as permissões de catálogo e isolar os processos do banco de dados no nível do sistema operacional.