O Ubuntu sempre foi considerado um dos sistemas Linux mais seguros e amigáveis, mas recentemente três brechas nas restrições de namespaces de usuário sem privilégios mostraram que até os melhores têm seus dias ruins. Você coloca um monte de travas de segurança, e os invasores encontram não uma, não duas, mas três maneiras completamente diferentes de passar por elas. Algumas dessas brechas usam ferramentas que já vêm instaladas por padrão no sistema.
Namespaces sem privilégios
Para entender a bagunça, precisamos falar sobre namespaces de usuário no Linux. Namespaces são como apartamentos num condomínio: você pode ser o “dono” do seu apartamento (ter privilégios de root dentro do namespace), mas você não tem uma chave mestra para entrar em todas as residências (o sistema principal). Essa funcionalidade é extremamente útil para containers e virtualização, mas também é um prato cheio para quem quer explorar falhas no kernel.
Preocupada com isso, a Canonical introduziu no Ubuntu 23.10 restrições baseadas no AppArmor para limitar o que usuários sem privilégios podem fazer dentro desses namespaces. Na versão 24.04, essas restrições já vieram ativadas por padrão. Tudo parecia perfeito até que os pesquisadores da Qualys apareceram com más notícias: “Olha, temos três maneiras de contornar essas proteções”. E não foram brechas complicadas – foram falhas que pessoas com conhecimento não tão avançado e acesso local poderia explorar.
Golpe do aa-exec
O aa-exec é como um passe-livre no mundo do AppArmor: ele permite executar programas sob perfis específicos de segurança. A ironia? Alguns desses perfis – como trinity, chrome e flatpak – permitem justamente o que as restrições tentam evitar: a criação de namespaces com privilégios totais. Um invasor pode simplesmente rodar unshare através de um desses perfis e voilà – tem um namespace privilegiado.
O mais engraçado (se é que podemos chamar de engraçado) é que já existia uma mitigação conhecida: ativar kernel.apparmor_restrict_unprivileged_unconfined=1. Mas adivinha? Não vem habilitada por padrão.
Ataque pelo Busybox
Busybox é uma ferramenta versátil e popular entre administradores de sistemas Linux. Ele está presente em praticamente todas as instalações do Ubuntu, servindo como uma versão compacta de vários comandos essenciais. Só que seu perfil no AppArmor permite a criação livre de namespaces. Um invasor pode abrir um shell via Busybox e, a partir dele, obter privilégios elevados.
A solução recomendada é desabilitar o perfil amplo do Busybox, mas isso pode quebrar funcionalidades legítimas. É o clássico dilema entre segurança e usabilidade – escolha seu veneno.
Invasão pelo LD_PRELOAD
Se por acaso as duas primeiras brechas forem fechadas, ainda tem uma terceira opção: o velho truque do LD_PRELOAD. Essa técnica permite injetar código em processos confiáveis, como o Nautilus (o gerenciador de arquivos padrão do GNOME). Como o Nautilus tem um perfil AppArmor permissivo, um invasor pode usá-lo como cavalo de Troia para ganhar privilégios.
A mitigação aqui envolve ou desativar o perfil do Nautilus (e perder algumas funcionalidades) ou criar um perfil mais restritivo para o bwrap, ferramenta que ele usa internamente. Novamente, segurança versus conveniência.
“Não são vulnerabilidades, são… características?”
O mais interessante nessa história toda foi a resposta da Canonical. Eles reconheceram os problemas, mas classificaram como “limitações de um mecanismo de defesa em profundidade”, não como vulnerabilidades críticas. Em outras palavras: “Sim, tem uns furos, mas já é melhor que nada”.
As correções devem vir em atualizações regulares, não como patches de emergência. Enquanto isso, administradores de sistema que se preocupam com segurança precisam aplicar as mitigações manuais.
Se tem uma lição que podemos tirar dessa história, é que segurança em sistemas operacionais é um jogo constante de gato e rato. Você adiciona uma camada de proteção, os invasores encontram um jeito de contorná-la, e o ciclo se repete. O Ubuntu ainda é uma distribuição segura, mas como qualquer sistema complexo, não é perfeito.
Para usuários comuns, essas brechas provavelmente não são motivo para pânico. Mas para administradores de sistemas corporativos ou servidores críticos, é mais um lembrete da importância de manter sistemas atualizados, monitorar logs e – quando possível – aplicar camadas extras de segurança.
Fique por dentro das principais novidades da semana sobre tecnologia e Linux: assine nossa newsletter!
