Há alguns dias, a empresa de segurança cibernética Qualys revelado por meio de uma postagem no blog a descoberta de dois gravevulnerabilidades que afetam diretamente apport e systemd-coredump, ferramentas amplamente utilizadas em sistemas Linux para gerenciar despejos de memória após falhas de processo.
As fallas, identificados como CVE-2025-5054 e CVE-2025-4598, expõem diversas distribuições a sérios riscos de vazamento de dados confidenciais armazenados na memória de processos privilegiados.
O risco oculto nos lixões
assim trazer (usado principalmente no Ubuntu) como systemd-coredump (usados no Red Hat, Fedora e outras distribuições) são responsáveis por processar os arquivos de núcleo gerados após uma falha do sistema. No entanto, essas ferramentas Eles apresentam uma condição de corrida que pode ser explorada por um invasor para acessar esses arquivos, mesmo quando eles vêm de aplicativos SUID ou processos do sistema com privilégios elevados.
Despejos de memória podem conter informações extremamente confidenciais., como hashes de senha extraídos de /etc/shadow, chaves de criptografia em cache ou dados de autenticação. Se um invasor explorar com sucesso essas vulnerabilidades, poderá ler esses dumps como um usuário normal, ignorando restrições que deveriam limitar o acesso apenas ao administrador do sistema.
Explorar vulnerabilidades no Apport e no systemd-coredump pode comprometer seriamente a confidencialidade. As consequências incluem tempo de inatividade operacional, danos à reputação e potencial não conformidade regulatória.
Como explorar falhas no Apport?
O vetor de ataque ao apport envolve uma técnica sofisticada:
- Um processo com privilégios suid, como unix_chkpwd, é iniciado, acessando dados confidenciais na memória.
- Antes de sua execução terminar, ela é interrompida com um sinal como SIGSEGV para forçar uma falha.
- Isso ativa o sistema de despejo de memória do Ubuntu, que inicia o apport automaticamente.
- No breve intervalo antes do apport analisar o dump, o invasor substitui o processo suid por um normal, usando namespaces separados e manipulações de PID para enganar o sistema.
- Como resultado, o apport processa e salva o despejo de memória com permissões normais, permitindo que o usuário invasor acesse livremente seu conteúdo.
Este método Foi comprovado como bem-sucedido no Ubuntu 24.04, indicando que outras versões e distribuições com comportamento semelhante também podem estar em risco.
Ataques direcionados ao systemd-coredump: menos etapas, mesmo perigo
No caso do systemd-coredump, o ataque é mais direto e não requer a substituição de processos em namespaces separados. Basta causar uma correspondência entre AT_UID e AT_EUID, qualPermite manipular a interpretação do processo que causou a falha. Embora o systemd-coredump seja mais rápido para iniciar, por ser escrito em C, é possível torná-lo artificialmente mais lento. Passar um grande número de argumentos para o processo suid aumenta o tempo de processamento do arquivo cmdline, gerando o intervalo de tempo necessário para executar a substituição.
Além disso, os pesquisadores descobriram que o systemd-coredump não utiliza corretamente o sinalizador %d em core_pattern, permitindo ataques contra processos de sistema não SUID, como sshd-session, sd-pam ou cron. Essa omissão abre caminho para a extração de chaves privadas, dados de pilha, hashes de senha e valores usados para contornar proteções como ASLR.
Mitigação e medidas recomendadas
Dada a gravidade do problema, recomenda-se uma ação imediata:
- Desabilitar despejos de memória para programas suid: Isso pode ser feito definindo o parâmetro suid_dumpable como 0, o que impede que esses processos gerem despejos acessíveis.
- Atualizar pacotes afetados: as principais distribuições já estão preparando atualizações para corrigir essas vulnerabilidades.
Embora a mitigação da vulnerabilidade seja um primeiro passo, menciona-se que a solução requer modificações no kernel do Linux. Em particular, Sugere-se implementar um sistema que utilize pidfd em vez de identificadores pid tradicionais, Como o pidfd está vinculado a processos específicos e não é reatribuído, isso impediria que um processo fosse assumido durante o intervalo de tempo entre a falha e a criação do dump.
Por fim, se estiver interessado em saber mais sobre o assunto, pode consultar os detalhes no link a seguir