Sobre uma vulnerabilidade que não é

imagem
No final de março de 2019, a empresa americana Trustwave, que atua nos serviços de segurança cibernética e proteção contra ameaças, publicou uma mensagem sobre uma vulnerabilidade no DBMS do PostgreSQL, presente em todas as versões, desde o PostgreSQL 9.3 até a versão 11.2. Esta vulnerabilidade foi registrada no banco de dados de vulnerabilidades de segurança da informação CVE (Common Vulnerabilities and Exposures) sob o número CVE-2019-9193 . Essa mensagem causou um grande alvoroço porque, de acordo com o sistema de classificação de vulnerabilidades CVSS (Common Vulnerability Scoring System), essa vulnerabilidade foi classificada como 9.0 em uma escala de 10 pontos.


As vulnerabilidades foram atribuídas às seguintes características:


  • Impacto da confidencialidade (influência na confidencialidade) - a divulgação completa de informações leva à divulgação de todos os arquivos do sistema.
  • Impacto na integridade (impacto na integridade) - uma perda completa da proteção do sistema, como resultado, todo o sistema fica comprometido.
  • Impacto na disponibilidade - a disponibilidade de um recurso está completamente indisponível.
  • A complexidade do acesso é baixa. O uso requer muito pouco conhecimento ou habilidades.
  • Autenticação - requer que um invasor efetue login no sistema, por exemplo, através da linha de comando ou de uma sessão da área de trabalho ou interface da web.
  • Acesso obtido - não.
  • Tipo (s) de vulnerabilidade (tipo de vulnerabilidade) - execução do código.

Agora vamos descobrir o que realmente acontece.


Em 2013, no PostgreSQL 9.3, foi adicionada uma confirmação, que, por analogia com o comando \ copy meta no psql, permite mover dados entre tabelas do PostgreSQL e arquivos regulares no sistema de arquivos. COPY TO copia o conteúdo da tabela para o arquivo e COPY FROM - do arquivo para a tabela (adiciona dados aos que já estão na tabela). Ao contrário do meta-comando \ copy, implementado no cliente, o comando COPY..TO / FROM é implementado no lado do servidor. O comando COPY possui um parâmetro opcional PROGRAM 'command', que permite ao servidor executar o 'command' e passar a saída padrão para o servidor PostgreSQL ou vice-versa. Foi esse parâmetro que causou pânico e a mensagem sobre a vulnerabilidade, pois, de acordo com a Trustwave, este comando permite executar código arbitrário no contexto do usuário do sistema operacional. No entanto, é exatamente isso que os desenvolvedores pretendem! Nesta ocasião, houve uma postagem oficial do Grupo de Desenvolvimento Global do PostgreSQL (PGDG), além de correspondência na lista de email pgsql-general (CVE-2019-9193 sobre COPY FROM / TO PROGRAM ) e comentários dos principais desenvolvedores, por exemplo, Magnus Hagander, em seu blog .


Mas, para entender a essência, os detalhes são importantes. Aqui está o que está escrito na documentação sobre isso: " Observe que o comando é iniciado por meio do shell de comando; portanto, se você deseja passar argumentos para este comando de uma fonte não confiável, você deve se livrar cuidadosamente de todos os caracteres especiais que tenham um significado especial no shell, ou para selecioná-los. Por motivos de segurança, é melhor limitar-se a uma linha de comando fixa ou, pelo menos, não permitir que os usuários insiram conteúdo arbitrário nela . "


Além disso, a documentação diz que apenas os superusuários do banco de dados têm permissão para executar o comando COPY com um arquivo ou um comando externo ou (na versão 11 apareceu) membros das funções internas pg_read_server_files, pg_write_server_files ou pg_execute_server_program, pois isso permite ler / gravar arquivos e executar qualquer arquivo programas aos quais o servidor tem acesso. A execução de um comando no PROGRAM pode ser limitada por outros mecanismos de controle de acesso que operam no SO, por exemplo, SELinux.


Estruturalmente, não há limite de segurança entre o superusuário do banco de dados e o usuário do sistema operacional em cujo nome o processo do servidor está em execução. As funções para COPY ... PROGRAM adicionadas no PostgreSQL 9.3 não alteraram nenhuma das opções acima, mas adicionaram um novo comando dentro dos mesmos limites de segurança que já existiam. Portanto, o servidor PostgreSQL não pode ser executado como superusuário do sistema operacional (por exemplo, root).


A própria funcionalidade COPY..TO / FROM ... PROGRAM oferece possibilidades ilimitadas para manipulação de dados, pós-processamento de dados, compactação de dados em tempo real e assim por diante. E proibir o uso de tais ferramentas úteis seria errado. Exemplos da construção COPY..TO / FROM ... PROGRAM são fornecidos no blog de Michael Paquier.


Uma conclusão importante que se segue desta história é que, ao projetar e criar bancos de dados, é necessário lembrar não apenas as características funcionais, mas também a segurança da informação e seguir as seguintes regras:


  • Ao criar usuários comuns no banco de dados, não conceda a eles permissões de superusuário, apenas o usuário do sistema operacional postgres, em nome do qual o servidor foi iniciado, atuará no banco de dados como superusuário. Nesse caso, não há escalação de privilégios. Se você der permissão ao superusuário a um usuário comum do banco de dados, isso será equivalente a emitir ao usuário as permissões que o usuário do postgres possui no sistema operacional.
  • Use os recursos do pg_hba.conf para garantir que nenhum superusuário possa efetuar login remotamente.
    Se não houver linhas anteriores com "host" no arquivo pg_hba.conf, a entrada a seguir proíbe o usuário do postgres de conectar-se a qualquer banco de dados a partir de qualquer endereço usando o protocolo tcp / ip.

    # TYPE DATABASE USER ADDRESS METHOD host all postgres 0.0.0.0/0 reject 
  • Use técnicas avançadas de segurança da informação no PostgresSQL, como o CIS PostgreSQL Benchmark e o PostgreSQL Security Technical Implementation Guide (STIG) .
  • Use produtos certificados para os quais foi confirmada a conformidade com os requisitos funcionais de segurança da informação e o nível de confiança nas ferramentas de segurança da informação.

Assim, descobrimos que o CVE-2019-9193 não é uma vulnerabilidade. Mas você não deve relaxar. Não perca informações sobre atualizações e novos lançamentos secundários que corrigem vulnerabilidades identificadas , sem as quais nem um único projeto grande pode fazer.

Source: https://habr.com/ru/post/pt448750/


All Articles