Imagine você confiando no sudo para isolar comandos administrativos críticos em servidores Linux ou Unix. A ideia é interessante, até que duas falhas antigas colocaram tudo a perder. Hoje é dia de mostrar como riscos sutis se escondem no trivial e por que você precisa agir “ontem”.
Antes de qualquer coisa, entenda o sudo: é essa ferramenta que permite a usuários sem privilégios executar comandos como outro usuário, tipicamente o root, mas sob restrições definidas em /etc/sudoers — um arquivo que dita “quem pode executar o quê, como quem e em quais máquinas”. Se você tem sudo distribuído via LDAP ou SSSD, atenção redobrada.
A primeira falha, CVE‑2025‑32462 (CVSS 2.8), é praticamente um fantasma que viveu camuflado por mais de 12 anos. Ela risca o sudo com a opção ‑h (host), introduzida em 2013, e permite que permissões destinadas a um host remoto sejam aplicadas ao host local simplesmente por listar privilégios de forma equivocada.
Em ambientes que replicam sudoers para vários servidores ou usam sudoers centralizado em LDAP, um usuário listado para um host remoto pode executar comandos autorizados lá diretamente na sua máquina. Ironia fina, você distribuiu sudoers para facilitar a administração e acabou abrindo uma brecha séria. A descoberta é creditada a Rich Mirch, da Stratascale .
A segunda falha, CVE‑2025‑32463 (CVSS 9.3), é bem mais severa. Ela explora a opção ‑R (chroot) do sudo e permite que qualquer usuário local mesmo sem regras específicas no sudoers ganhe acesso root criando um arquivo /etc/nsswitch.conf sob um diretório controlado. O sudo acaba carregando essa configuração e permite execução de comandos arbitrários. O resultado? Um invasor local vira root mesmo sem permissão explícita.
O impacto dessas vulnerabilidades merece uma pausa. A primeira é bem óbvia por ser de severidade média, mas afeta infraestruturas LDAP ou comum de sudoers. A segunda, crítica, está presente até mesmo na configuração padrão do sudo e afeta qualquer instalação anterior à versão 1.9.17p1. Essa possibilidade de escalada de privilégios sem senha, sem regras, dentro da própria máquina é praticamente um presente para invasores locais.
A comunidade sudo adotará uma mudança drástica, removerá completamente a opção chroot de futuras versões, por considerá-la muito propensa a erros .
Essas falhas foram divulgadas com responsabilidade em 1º de abril de 2025 e corrigidas na versão 1.9.17p1 lançada ainda no mês seguinte. As principais distribuições Linux já publicaram atualizações: Alpine, Ubuntu, Debian, Red Hat, SUSE, Gentoo, Amazon Linux, AlmaLinux e Oracle Linux, com escopo variando de modelo a modelo.
Sua checklist prática agora:
- Atualize para sudo 1.9.17p1 ou superior
- Verifique se suas máquinas compartilham sudoers centralizados ou distribuídos por LDAP/SSSD
- Evite utilizar a opção chroot até que seja removida ou corrigida pelo projeto sudo
- Teste seu ambiente: usuários listados em um host remoto não devem conseguir executar comandos no host local
Você já atualizou suas máquinas para sudo 1.9.17p1 ou superior? Algum servidor ainda depende de sudoers distribuído via LDAP ou SSSD? Você já testou se chroot ou host listings estão expondo comandos indevidos nas suas máquinas?
Se não, qual passo você vai tomar hoje para mitigar esses riscos? Deixe seu comentário!
