O Postgres gerenciado acaba de ganhar um grande hack

Ver no idioma original →

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Hosted Postgres Just Got Major Hack · Canal: Better Stack · 01:01 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Dados, bancos de dados e embeddings, Engenharia de software com IA, Infraestrutura e hardware de IA

Resumo

Um pesquisador de segurança encontrou uma forma de contornar o bloqueio de comandos em serviços de Postgres gerenciado. Ele recriou uma função bloqueada com outro nome, gravou uma biblioteca compilada no disco e a executou como usuário do sistema Postgres no host. O método funcionou em todos os provedores testados; Supabase corrigiu quatro problemas críticos, enquanto outros fornecedores não responderam. A técnica não dá acesso aos dados de outros clientes, mas permite executar código no host e obter um ponto de apoio na infraestrutura do provedor.

Pontos-chave

• Provedores de Postgres gerenciado reservam o acesso de superuser para si e limitam os comandos disponíveis aos clientes.
• Uma extensão bloqueava comandos perigosos pelo nome, mas não impedia a recriação da mesma função com outro nome.
• O pesquisador gravou uma biblioteca compilada no disco do servidor e a registrou como uma função do Postgres.
• A biblioteca foi executada como usuário do sistema Postgres no host.
• O método funcionou em todos os provedores testados pelo pesquisador.
• Supabase corrigiu quatro problemas críticos; a maioria dos outros fornecedores não respondeu.
• A equipe principal do Postgres considerou que o problema cabe aos provedores, não ao projeto Postgres.
• A falha permite execução de código no host e acesso inicial à infraestrutura do provedor, mas não concede acesso aos dados de outros clientes.

Capítulos

Início	Capítulo	Resumo
00:00	O bloqueio de comandos no Postgres gerenciado	O vídeo explica como provedores restringem comandos perigosos e apresenta a função allow_export.
00:30	Contorno do bloqueio e execução de código	O pesquisador recria a função com outro nome, grava uma biblioteca no disco e a executa no host.
01:01	Impacto e limites da falha	A técnica não expõe dados de outros clientes, mas permite executar código no host e alcançar a infraestrutura do provedor.

Citações

Este pesquisador de segurança acabou de encontrar uma maneira totalmente nova de hackear o Postgres. — 00:00

Ele recriou exatamente a mesma função com um novo nome que a lista de bloqueio nunca tinha visto. — 00:30

O Postgres executou o código dele como usuário do sistema Postgres, diretamente no host. — 00:30

O que isso realmente permite é executar código no host onde seu banco de dados funciona e obter um ponto de apoio na infraestrutura do provedor. — 01:01

Conceitos e entidades

• PostgreSQL (ferramenta): Banco de dados usado nos serviços gerenciados mencionados e no qual a técnica demonstrada permite executar código no host.
• Supabase (empresa): Provedor de Postgres gerenciado que, segundo o vídeo, corrigiu quatro problemas críticos.
• Aurora (ferramenta): Serviço de Postgres gerenciado citado como exemplo no vídeo.
• Neon (empresa): Provedor de Postgres gerenciado citado como exemplo no vídeo.
• allow_export (conceito): Nome de um comando mencionado como bloqueado, capaz de extrair dados do banco e gravá-los em um arquivo no servidor.
• superuser (conceito): Papel administrativo do Postgres que os provedores mantêm para si nos serviços gerenciados.
• Better Stack (empresa): Canal do YouTube que publicou o vídeo.

Tradução completa (pt-BR)

00:00 Este pesquisador de segurança acabou de encontrar uma maneira totalmente nova de hackear o Postgres. Deixe-me explicar. Quando você aluga um Postgres gerenciado, como Superbase, Aurora ou Neon, eles nunca lhe dão acesso de superusuário. O provedor mantém o superusuário para si e adiciona uma extensão que bloqueia, pelo nome, os comandos mais perigosos do Postgres, mesmo para a função mais poderosa que você recebe. Um desses comandos bloqueados se chama allow_export. Ele extrai dados do seu banco de dados e os grava em um arquivo em qualquer lugar do disco do servidor, mas a extensão só o bloqueia pelo nome. Então, o pesquisador

00:30 recriou exatamente a mesma função com um novo nome que a lista de bloqueio nunca tinha visto. Depois, usou-a para gravar uma biblioteca compilada no disco. Em seguida, registrou essa biblioteca como uma função, chamou-a, e o Postgres executou o código dele como um usuário de sistema do Postgres diretamente no host. Ele conseguiu fazer isso em todos os provedores que testou. A Superbase corrigiu quatro problemas críticos, e a maioria dos outros fornecedores simplesmente ficou em silêncio. E a própria equipe principal do Postgres disse que esse é um problema que cabe ao provedor resolver, não a eles. Mas ter acesso de superusuário aqui não significa que está tudo acabado. Isso não lhe dá acesso aos dados de outros clientes, e você já podia ler sua própria instância de qualquer maneira. O que isso realmente lhe dá é execução de código no host em que seu banco de dados funciona e um ponto de apoio na infraestrutura do provedor. E, se você gosta de análises aprofundadas de segurança como esta, inscreva-se no Better Stack.

01:01 aos dados de outros clientes, e você já podia ler sua própria instância de qualquer maneira. O que isso realmente lhe dá é execução de código no host em que seu banco de dados funciona e um ponto de apoio na infraestrutura do provedor. E, se você gosta de análises aprofundadas de segurança como esta, inscreva-se no Better Stack.

Transcrição original

[00:00] This security researcher just found a brand new way to hack Postgres. Let me explain. When you rent a managed Postgres like Superbase, Aurora, or Neon, they never give you superuser. The provider keeps superuser to itself and adds an extension that blocks Postgres’s most dangerous commands by name even for the most powerful role that you get. One of those blocked commands is called allow_export. It pulls data out of your database and writes it to a file anywhere on the server’s disk, but the extension only blocks it by name. So, the researcher

[00:30] recreated that exact same function under a new name the blocklist had never seen before. He then used it to write a compiled library onto disk. Then, he registered that library as a function, called it, and Postgres ran his own code as a Postgres system user right on the host. He managed to do this successfully across every single provider he tested. Superbase patched four critical issues, and most other vendors just went silent. And Postgres’s own core team said this is the provider’s problem to fix, not theirs. But superuser here isn’t actually game over. It doesn’t hand you

[01:01] other customers’ data, and you could already read your own instance anyway. What it really gives you is code execution on the host your database runs on and a foothold onto the provider’s infrastructure. And if you like security deep dives like this, then subscribe to Better Stack.