Um estudo de caso de divulgação do Lakebase Postgres
por Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava e Alexey Kondratov
Alguns dos nossos melhores investimentos em segurança não foram ferramentas ou scanners. Foram em relacionamentos. A Databricks mantém um programa de bug bounty porque a maneira mais rápida de encontrar os pontos fracos em uma plataforma é permitir que pessoas talentosas e curiosas os procurem, garantindo que, quando encontrarem algo, um relatório de boa-fé receba uma resposta de boa-fé. A maioria dos relatórios é uma transação silenciosa: alguém encontra um bug, nós o corrigimos e todos seguem em frente.
De vez em quando, um deles se transforma em uma história genuinamente boa. Esta é uma delas.
Há algumas semanas, um pesquisador externo, Mehmet Ince, nos mostrou um bug de segurança de memória em uma extensão do Postgres que é enviada em plataformas Postgres gerenciadas, incluindo o Lakebase Postgres e o Neon. O que fez valer a pena escrever sobre isso não foi apenas o bug. Foi o que aconteceu ao redor dele: como nossa detecção capturou os testes dele, a rapidez com que pudemos proteger os clientes e como a correção real acabou voltando para onde deveria. No open source, para todos que executam a mesma extensão, não apenas para nós.
Se você gerencia uma equipe de segurança, opera uma infraestrutura open source gerenciada ou apenas tem curiosidade sobre como é uma interação saudável entre pesquisador e fornecedor de ambos os lados, este texto é para você. Mehmet escreveu a história detalhada da exploração técnica em seu próprio blog. Aqui, queremos falar sobre a colaboração.
| O blog do Mehmet faz referência à exposição de dados entre clientes em uma plataforma diferente. A Databricks executa o Lakebase Postgres e o Neon em uma arquitetura de microVM que fornece um limite de segurança forte entre as instâncias de computação. O exploit do Mehmet não resultou em nenhum impacto entre clientes na Databricks. |
|---|
O ecossistema de extensões do Postgres é um dos principais fatores de sua popularidade e, embora o suporte varie de acordo com o fornecedor, os clientes esperam que os provedores gerenciados ofereçam suporte às opções principais e de terceiros mais utilizadas. Uma delas é o PostGIS, o kit de ferramentas geoespaciais. Dentro do PostGIS, há uma extensão menor e discreta chamada address_standardizer que transforma um endereço não estruturado como 123 Main St em um formato normalizado.
Mehmet descobriu que a address_standardizer tinha uma falha clássica de segurança de memória: um valor totalmente controlado por quem faz a chamada (parte de uma "regra" gramatical que quem chama pode fornecer) era usado para indexar um array interno de tamanho fixo sem uma verificação de limites. Se você fornecer um valor fora do intervalo, obterá um acesso de memória fora dos limites.
A parte importante para um serviço Postgres gerenciado é quem pode acessá-lo. A address_standardizer está no conjunto de extensões que um tenant normal pode instalar e usar. Portanto, este não era um bug que exigia privilégios especiais para ser acessado. Uma função de cliente comum poderia chamar a função e alcançar o caminho de código vulnerável. Essa é exatamente a propriedade que transforma um bug silencioso e fácil de ignorar em algo que uma equipe de plataforma precisa levar a sério.
Estamos mantendo os detalhes da exploração superficiais aqui de propósito. A análise detalhada do Mehmet explica a primitiva de forma adequada, e ele faz isso melhor do que um resumo faria.
Por Mehmet D. Ince
A história não começou como uma pesquisa de vulnerabilidade. Na primavera deste ano, durante uma reunião interna, minha equipe perguntou se poderíamos migrar algumas de nossas instâncias do PostgreSQL para um provedor gerenciado. Como CTO da PRODAFT, uma empresa europeia de inteligência contra ameaças com cerca de 50 engenheiros, uma das minhas responsabilidades é garantir que ofereçamos os serviços mais seguros possíveis aos nossos clientes.
Nós mesmos vínhamos executando o PostgreSQL por mais de uma década, mas eu nunca tinha analisado adequadamente como os provedores de Postgres gerenciado entregavam esses serviços sob a perspectiva de segurança. Faço pesquisas de vulnerabilidade desde o início dos anos 2000, então sempre me dou uma pequena janela para fazer algumas pesquisas de segurança e entender melhor o risco que estamos correndo simplesmente ao adicionar outra tecnologia à nossa infraestrutura. Sem surpresa, minhas "análises rápidas" tendem a terminar com um relatório de vulnerabilidade crítica na caixa de entrada de alguém. Alguns hábitos são difíceis de deixar para trás.
Após alguns dias de pesquisa, percebi que quase todos os provedores enviam praticamente as mesmas extensões do Postgres. Uma vulnerabilidade de corrupção de memória em uma extensão amplamente implantada é, na prática, uma vulnerabilidade de corrupção de memória no próprio PostgreSQL. Por isso, escolhi como alvo uma extensão chamada address_standardizer, uma pequena extensão do PostGIS disponível literalmente em qualquer lugar.
Em uma segunda-feira à noite, por volta das 19h aqui em Londres, o Aaron me enviou um e-mail de forma bastante inesperada, perguntando se a atividade que acionou os alarmes de produção do Neon era minha. Eu estava trabalhando na portabilidade do meu exploit funcional para instâncias do Neon PostgreSQL para ver se um único bug simples em uma extensão pequena e inofensiva poderia realmente expor um caminho de escalada de privilégios ali. Eu tinha uma PoC funcional, mas enviei a ele apenas uma captura de tela. Aquela única captura de tela foi suficiente para ele começar a agir!
Faço a divulgação responsável de vulnerabilidades para fornecedores há mais de duas décadas e, mesmo depois de todos esses anos, ainda é difícil explicar o impacto e os riscos das descobertas sem gastar muito tempo procurando o contato certo para conversar. Devo dizer, parabéns ao Aaron e à equipe de segurança da Databricks por entrarem em contato proativamente com pesquisadores dessa forma e tomarem uma atitude tão rápida!
Veja o post do Mehmet para mais informações.
Do nosso lado da mesa, este é um estudo de caso de divulgação coordenada funcionando da maneira que deveria.
O Mehmet compartilhou sua prova e, até o final do dia, o relatório já havia circulado entre as pessoas certas, com nossos engenheiros de segurança validando-o em relação à versão exata do PostGIS que o Neon envia. Confirmamos que o caminho de código vulnerável era acessível por uma função de tenant normal e o tratamos de acordo.
Logo no início, tomamos uma decisão deliberada que achamos que vale a pena detalhar, porque é uma questão que toda equipe de plataforma acaba enfrentando: um bug em um componente open source que você envia ainda é problema seu. A causa raiz estava no upstream do PostGIS, mas a exposição era nossa. Colocamos essa extensão à disposição dos tenants por padrão, então o impacto era de nossa responsabilidade. Não a descartamos como "de terceiros". Em vez disso, aceitamos o relatório, conduzimos a resposta e recompensamos o pesquisador que o enviou.
Também não estávamos dispostos a ficar limitados ao cronograma de lançamento do upstream enquanto os clientes estivessem expostos. Nosso sistema de build de extensões é intencionalmente projetado para que possamos aplicar um conjunto arbitrário de patches sobre qualquer extensão Postgres do upstream antes de compilá-la e empacotá-la, seja fazendo o backport de uma correção ou desativando um caminho de código arriscado em nosso próprio build. Como esse conjunto de patches reside no downstream e não no código-fonte do upstream, podemos agir independentemente de quando o upstream lança uma versão. Assim, pudemos agir rapidamente para proteger os clientes e trabalhar em paralelo para corrigir o ecossistema adequadamente.
Construir a correção definitiva levou algumas iterações. A primeira tentativa não cobriu todos os casos, e preferimos levar uma semana extra e fazer a coisa certa do que lançar algo incompleto. A correção reforçada foi implantada para proteger os tenants do Neon e do Lakebase, que não precisaram tomar nenhuma ação por conta própria.
Aqui é onde a história fica interessante e com um pouco de sorte.
A correção canônica pertencia ao PostGIS. É o código deles, o lançamento deles, a decisão deles. A Databricks agradece aos mantenedores do PostGIS, que mantêm uma peça fundamental do mundo geoespacial funcionando em grande parte como voluntários. O Mehmet claramente sentiu o mesmo e fez algo a respeito: ele doou sua recompensa para o projeto PostGIS e igualou o valor do próprio bolso, direcionando a recompensa diretamente de volta ao esforço voluntário em cujo código toda a indústria de Postgres gerenciado se apoia. Nosso plano era simples: proteger nossos clientes primeiro e, depois, trabalhar com o Mehmet para corrigir a causa raiz no upstream para que todos que executam a address_standardizer se beneficiem, não apenas o Neon.
Então, uma coincidência complicou as coisas. Quase ao mesmo tempo, o bug subjacente foi corrigido no upstream, como uma pequena correção de vazamento de memória, sem um CVE e sem alarde.
A correção upstream, no fim das contas, não cobriu todos os casos. Mehmet validou exatamente onde ela falhou e enviou as partes restantes de volta para o upstream, fechando a lacuna para toda a comunidade. Nenhum CVE foi atribuído para a cadeia, o que é uma pequena lição sobre como é fácil para uma correção significativa de segurança de memória passar despercebida em uma nota de lançamento como uma limpeza "menor".
A principal lição que tiramos disso: o pesquisador pôde fazer a coisa certa com a causa raiz, o upstream recebeu uma correção completa e nossos clientes já estavam protegidos enquanto tudo isso acontecia.
Se você opera um serviço gerenciado baseado em componentes open source (um banco de dados gerenciado, qualquer coisa gerenciada), a verdade desconfortável nesta história é que sua superfície de ataque inclui código que você não escreveu e um modelo de ameaça com o qual seus autores talvez nunca tenham concordado. Uma extensão pequena, popular e pouco ativa é exatamente o tipo de coisa fácil de implantar e fácil de esquecer.
Algumas coisas que funcionaram para nós e podem funcionar para você:
Se você é um pesquisador de segurança, gostaríamos muito de falar com você. Especialmente quando você puder demonstrar um impacto real e mensurável na plataforma, como o Mehmet fez. Envie seu relatório por meio de hackerone.com/databricks.
Agradecemos a Mehmet Ince pelo relatório bem documentado e de boa-fé, e por fazer a coisa certa com a causa raiz no upstream. Agradecemos aos mantenedores do PostGIS, cujo trabalho em open source é uma parte essencial do mundo geoespacial que depende dele. E agradecemos aos engenheiros da Neon e da Lakebase, que transformaram um relatório em uma correção implantada de forma rápida e tranquila.
A todos os pesquisadores que trabalham conosco para tornar a plataforma mais segura: reconhecemos o seu esforço e somos muito gratos. Nos vemos no HackerOne.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.