Foram divulgadas informações sobre uma nova vulnerabilidade crítica que foi descoberto no utilitário Sudo (a ferramenta de gerenciamento de privilégios mais amplamente utilizada no Linux).
Listado como CVE-2025-32463, esta falha permite que qualquer usuário local sem privilégios execute comandos com acesso root, mesmo que não esteja listado na configuração do sudoers. A falha foi verificada em distribuições populares como Ubuntu 24.04 e Fedora 41, afetando suas configurações padrão.
A origem do problema está na opção –chroot (-R) de Sudo, que permite que você execute comandos em um ambiente de sistema de arquivos isoladoAo usar esta opção, o Sudo altera o diretório raiz para o especificado pelo usuário. O perigo é que, nesse processo, o Sudo carregue o arquivo /etc/nsswitch.conf do ambiente chroot, e não do sistema original.
A configuração padrão do Sudo é vulnerável. Embora a vulnerabilidade afete a funcionalidade chroot do Sudo, ela não exige a definição de regras do Sudo para o usuário. Portanto, qualquer usuário local sem privilégios pode aumentar seus privilégios para root se uma versão vulnerável for instalada. As seguintes versões são conhecidas por serem vulneráveis. Observação: Nem todas as versões dentro do intervalo foram testadas.
Isso abre a porta para um ataque engenhoso.: Se o usuário criar seu próprio ambiente chroot e incluir um arquivo nsswitch.conf manipulado nele, ele poderá forçar o sistema a carregar bibliotecas compartilhadas personalizadas localizadas nesse ambiente. Como o NSS (Troca de serviço de nomes) executa o código antes de abrir mão dos privilégios de root, o invasor consegue fazer com que seu código malicioso seja executado com privilégios de superusuário.
CVE-2025-32463: Prova de conceito e detalhes técnicos
A exploração deste vulnerabilidade foi demonstrada com um exploit no Bash que usa uma biblioteca compartilhada personalizada e um arquivo de configuração modificado. Ao executar sudo -R uau uau Neste ambiente, o sistema carrega a biblioteca com privilégios de root, resultando em escalada direta de privilégios.
Emborae chroot é comumente usado para limitar o acesso ao sistema de arquivos, como ocorre em servidores FTP ou SFTP, Não foi projetado como uma medida de segurançaNa verdade, o próprio manual do Linux alerta: chroot() apenas altera o diretório raiz do processo, mas não impede chamadas perigosas nem fornece isolamento real.
No Sudo, a opção -R alterna para root antes de executar o comando, o que pode ser útil em cenários específicos, mas também é extremamente arriscado se usuários sem privilégios tiverem permissão para definir o ambiente.
Este ataque foi verificado nas versões do Sudo de 1.9.14 a 1.9.17, embora se suspeite que possa afetar a partir da versão 1.8.33. No entanto, versões mais antigas (≤ 1.8.32) não são vulneráveis, pois não implementam a função chroot.
Outra vulnerabilidade relacionada: CVE-2025-32462
La A atualização que corrige esse problema também aborda uma segunda vulnerabilidade., identificado como CVE-2025-32462, que permite ignorar restrições de host em sudoers.
Esta falha Ocorre quando o usuário utiliza a opção –host (-h) não apenas lista regras de privilégio, mas também executa comandos, o que não era intencional. Se o arquivo de configuração incluir regras como testuser testhost = ALL, um usuário poderá executar sudo -h testhost para executar comandos root em qualquer host, contornando assim as restrições.
No entanto, esta segunda falha Ela afeta apenas usuários que já estão no sudoers e cuja configuração específica inclui restrições de host..
Quais distribuições são afetadas?
A vulnerabilidade foi confirmada em:
- Ubuntu 24.04.1 com Sudo 1.9.15p5 e 1.9.16p2
- Fedora 41 com Sudo 1.9.15p5
As As versões vulneráveis variam de 1.9.14 a 1.9.17, É importante observar que a opção chroot está obsoleta desde o Sudo 1.9.17p1. Portanto, seu uso não é mais recomendado em ambientes de produção.
O que é recomendado fazer?
A equipe de pesquisa da Stratascale recomendou as seguintes ações:
- Atualize o Sudo para a versão 1.9.17p1 ou superior.
- Evite usar a opção chroot, pois sua funcionalidade foi descontinuada por motivos de segurança.
- Verifique o uso de runchroot= ou diretivas semelhantes em /etc/sudoers e nos arquivos dentro de /etc/sudoers.d.
- Revise os logs do sistema para entradas Sudo que usam CHROOT=.
- Use ferramentas como ldapsearch se suas regras sudoers estiverem armazenadas em LDAP.
Por fim, se estiver interessado em saber mais sobre o assunto, pode consultar os detalhes no link a seguir