A empresa Qualys identificou duas vulnerabilidades nas ferramentas apport (CVE-2025-5054) e systemd-coredump (CVE-2025-4598), que são utilizadas para processar arquivos core gerados após a finalização inesperada de processos. As vulnerabilidades permitem o acesso a arquivos core salvos após a finalização inesperada de aplicações suid ou de alguns processos de fundo do sistema, cuja memória pode conter credenciais ou chaves de criptografia em cache. O utilitário apport é acionado automaticamente para salvar os core dumps no Ubuntu, enquanto o systemd-coredump é utilizado no Red Hat Enterprise Linux 9+, Fedora e em muitas outras distribuições Linux.
Foi demonstrada uma técnica de ataque na qual se criaram condições para a finalização inesperada da aplicação suid unix_chkpwd e o acesso ao arquivo core com o dump de estado durante a falha. O core dump salvo continha hashes de senhas de usuários do sistema, que permaneceram na memória do processo que falhou após a leitura do conteúdo de /etc/shadow. A possibilidade de exploração das vulnerabilidades foi demonstrada no Ubuntu 24.04 e no Fedora 40/41, mas supõe-se que outras distribuições também estejam suscetíveis a ataques semelhantes.
Ambas as vulnerabilidades são causadas por uma condição de corrida que permite substituir o processo suid que falhou por outro processo no momento após o início do manuseio pelo núcleo da falha, mas antes que o manipulador verifique os parâmetros do processo no espaço do usuário através de /proc/pid/files. A chamada de apport e systemd-coredump ocorre da seguinte forma: o núcleo, ao receber informações sobre a falha do processo, chama o manipulador especificado no arquivo /proc/sys/kernel/core_pattern, e depois transmite o conteúdo do core dump através do fluxo de entrada.
A geração do core dump e a execução do manipulador não ocorrem instantaneamente, e esse tempo é suficiente para substituir o processo suid finalizado por um processo normal do usuário. Em caso de substituição, o manipulador de core dumps em execução considerará que a falha ocorreu não no processo suid, mas sim em uma aplicação comum do usuário e, consequentemente, salvará o arquivo core com acesso permitido ao usuário comum, e não apenas ao administrador.
O ataque ao apport consiste nos seguintes passos:
- Um novo processo é destacado e a função execve() é chamada para iniciar um programa suid, como unix_chkpwd.
- O tempo necessário para o carregamento de dados confidenciais pela aplicação suid na memória é desconsiderado (no caso de unix_chkpwd, espera-se o carregamento de hashes das senhas de todos os usuários do sistema a partir do arquivo /etc/shadow).
- Antes do término da execução do comando, o processo recebe um sinal SIGSEGV ou SIGSYS para um encerramento forçado.
- Em resposta ao encerramento forçado, o núcleo gera um core dump e inicia o processo apport para o tratamento do core dump no espaço do usuário.
- Após o início do apport, mas antes da análise, o processo que encerrou de forma inesperada recebe um sinal SIGKILL, e o próprio processo é substituído por outro sem a flag suid. Para contornar as verificações no apport, o novo processo é criado dentro de espaços de nomes separados (user, pid e mount namespace).
- O apport conecta-se ao socket unix /run/apport.socket no espaço de nomes de pontos de montagem criado para o novo processo e envia um descritor de arquivo para acesso ao core dump.
Para obter o identificador necessário para o novo processo, que corresponda ao identificador do processo suid, antes de enviar o sinal SIGSEGV, o processo suid é parado pelo sinal SIGSTOP e, durante a pausa, novos processos são iniciados ciclicamente até que um PID com um número anterior, próximo ao do processo suid a ser substituído, seja obtido. Após o deslocamento da numeração do PID, os sinais SIGSEGV e SIGCONT são enviados para o processo suid, seguido pelo SIGKILL, e novos processos são iniciados ciclicamente para alcançar o mesmo PID do processo suid.
No que diz respeito ao systemd-coredump, por um lado, executar um ataque contra ele é mais simples, pois não é necessário substituir o processo suid por um processo em um espaço de usuário separado, bastando conseguir a coincidência de AT_UID e AT_EUID. Por outro lado, o systemd-coredump é escrito em C e inicia rapidamente, o que oferece menos tempo para a substituição, ao contrário do apport, que é escrito em Python e carrega vários arquivos .pyc durante o processo de inicialização. Esse problema é resolvido através de um atraso artificial no systemd-coredump — ao chamar o arquivo suid, um número muito grande de argumentos de linha de comando é passado, criando o atraso necessário que ocorre durante a análise de /proc/pid/cmdline.
Durante a análise de vulnerabilidades, os pesquisadores também descobriram que o systemd-coredump, ao configurar a chamada, não especifica o flag «%d» em /proc/sys/kernel/core_pattern, o que permite que um atacante provoque uma falha em processos em segundo plano, executados com privilégios de root e que ramificam outros processos alterando o identificador do usuário para um usuário não privilegiado sob o qual o ataque é realizado. Essa possibilidade permite atacar não apenas aplicações setuid, mas também processos como sshd-session (OpenSSH), sd-pam (systemd) e cron, a fim de obter dados confidenciais que permanecem em sua memória, como chaves privadas, hashes de senhas do /etc/shadow, etiquetas canário da pilha e dados para contornar a randomização do espaço de endereçamento (ASLR).
É possível acompanhar a publicação de atualizações de pacotes nas distribuições nas páginas: Debian, Ubuntu, RHEL, openSUSE, Fedora, Gentoo, Arch. Como uma solução alternativa para bloquear as vulnerabilidades, recomenda-se desativar a gravação de core dumps para programas suid e processos que reduzem privilégios, definindo o parâmetro /proc/sys/fs/suid_dumpable como 0. Para eliminar completamente o problema, é necessária uma mudança no núcleo do Linux, que implemente a possibilidade de transmitir informações sobre o processo encerrado inesperadamente através do mecanismo pidfd (o pidfd está vinculado a processos específicos e, diferentemente do pid, não é reatribuído).
Fonte: opennet.ru
