Falha no systemd-coredump compromete o conteúdo da memória

Conheça os detalhes do problema e entenda como uma nova falha no systemd-coredump compromete o conteúdo da memória.

Foi divulgada a notícia de que uma vulnerabilidade (já listada em CVE-2022-4415) foi identificada no systemd-coredump, que lida com arquivos principais gerados após falhas de processo e pode permitir que um usuário local sem privilégios inspecione o conteúdo da memória de processos privilegiados em execução com o indicador root suid.

Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas.

Falha no systemd-coredump compromete o conteúdo da memória

Falha no systemd-coredump compromete o conteúdo da memória

systemd-coredump é um driver de despejo de núcleo de espaço de usuário para Linux que faz parte do pacote systemd. A vulnerabilidade se deve à falta de tratamento correto do parâmetro sysctl fs.suid_dumpable no systemd-coredump que, com o valor padrão de 2, permite a geração de core dumps para processos com o sinalizador suid.

Entende-se que os arquivos principais dos processos suid escritos pelo kernel devem receber direitos de acesso que permitam a leitura apenas pelo usuário root.

Chamado pelo kernel para salvar arquivos principais, o utilitário systemd-coredump salva o arquivo principal como root, mas também concede acesso baseado em ACL aos arquivos principais que podem ser lidos com base na ID do proprietário que originalmente iniciou o processo.

Esse recurso permite que você carregue arquivos principais sem considerar o fato de que o programa pode alterar o ID do usuário e executar com privilégios elevados.

O ataque se resume ao fato de o usuário poder iniciar um aplicativo suid e enviar a ele um sinal SIGSEGV, após o qual carrega o conteúdo do arquivo central, que inclui uma parte da memória do processo no momento da falha.

No e-mail onde o problema é relatado, é informado o seguinte:

A questão
=========

systemd-coredump define sysctl fs.suid_dumpable por padrão como 2 usando
um arquivo de configuração push sysctl.d. Para o despejo de núcleo interno do kernel
lidar com essa configuração significa que os dumps principais para setuid (ou de outra forma
privilegiados) os processos gravarão no disco, mas apenas
acessível ao usuário root para evitar o vazamento de dados confidenciais para
contas de usuários sem privilégios. Veja também `man 5 proc` para o completo
documentação deste sysctl.

systemd-coredump no espaço do usuário, porém não respeita este kernel
configuração na implementação de seu tratamento de dump principal. O ID de usuário real
de um processo de despejo receberá acesso de leitura ao despejo principal por meio de um
entrada ACL

Por exemplo, o usuário pode executar “/usr/bin/su” e terminar sua execução em outro terminal com o comando “kill -s SIGSEGV `pidof su`”, após o qual o systemd-coredump salvará o arquivo principal em /var/lib/systemd/ diretório coredump definindo uma ACL para ele que permite que o usuário atual o leia.

É mencionado que, como o utilitário suid ‘su’ lê o conteúdo de /etc/shadow na memória, um invasor pode acessar informações sobre os hashes de senha de todos os usuários no sistema. O utilitário sudo não é suscetível a ataques, pois proíbe a geração de arquivos principais via ulimit.

Quanto ao problema, foi confirmado na configuração padrão nas distribuições openSUSE, Arch, Debian, Fedora e SLES.

Segundo os desenvolvedores do systemd, a vulnerabilidade se manifesta a partir da versão 247 do systemd (lançada em novembro de 2020), mas segundo o pesquisador que identificou o problema, a versão 246 também é afetada.

A vulnerabilidade se manifesta se o systemd for compilado com a biblioteca libacl (padrão em todas as distribuições populares). A correção ainda está disponível como um patch.

Os interessados ​​em rastrear a correção nas distribuições podem fazê-lo nas seguintes páginas: Debian ,  Ubuntu ,  Gentoo ,  RHEL ,  SUSE ,  Fedora ,  Gentoo ,  Arch.

Por fim, vale a pena mencionar que, por enquanto, como uma solução de segurança temporária, os usuários podem definir sysctl fs.suid_dumpable como 0, o que desativa a transferência de dump para o driver systemd-coredump.

Deixe um comentário

Sair da versão mobile