CrackArmor: falhas no AppArmor expõem milhões de sistemas Linux a ataques críticos

Pesquisadores de segurança identificaram nove vulnerabilidades graves no AppArmor, mecanismo de proteção nativo do Linux. As falhas, agrupadas sob o nome CrackArmor, existem desde 2017 e podem impactar mais de 12,6 milhões de servidores empresariais ativos ao redor do mundo.

O AppArmor atua como uma camada de controle dentro do sistema, definindo o que cada aplicação pode ou não fazer. Ele já vem ativado por padrão em distribuições populares como Ubuntu, Debian e SUSE Linux Enterprise, o que amplia significativamente a superfície de ataque.

Importante: o problema não está no conceito do AppArmor, mas na forma como sua implementação foi feita dentro do kernel do sistema.

Como o ataque funciona

Para explorar as falhas, o invasor não precisa de privilégios administrativos — uma conta local comum já é suficiente.

A partir disso, ele interage com pseudo-arquivos do sistema localizados em:

/sys/kernel/security/apparmor/

Esses arquivos permitem carregar, alterar ou remover perfis de segurança. O problema é que, devido a uma falha de design, essas ações podem ser manipuladas sem autorização.

Esse tipo de vulnerabilidade é conhecido como Confused Deputy Problem — quando um componente confiável do sistema executa ações maliciosas acreditando estar seguindo instruções legítimas.

Na prática, é como convencer alguém com acesso total a abrir portas que deveriam permanecer fechadas.

Impacto: controle total do sistema

As consequências são pesadas. Um atacante pode escalar privilégios até o nível root, obtendo controle completo da máquina.

No espaço de usuário, a exploração envolve ferramentas comuns como o comando sudo. Ao manipular variáveis de ambiente e serviços como Postfix, é possível forçar o envio de comandos com privilégios elevados e obter acesso total.

Já no nível do kernel, o cenário fica ainda mais crítico. Uma falha do tipo use-after-free permite reescrever diretamente o arquivo /etc/passwd, onde ficam armazenadas as credenciais do sistema. Com isso, o invasor pode redefinir a senha do root e assumir o controle.

Além disso, o ataque pode:

  • causar travamentos completos do sistema (kernel panic)
  • bloquear serviços essenciais, como SSH
  • remover proteções de serviços críticos
  • vazar endereços de memória e quebrar o KASLR
  • escapar de contêineres e contornar restrições de segurança

Alcance global

O impacto vai muito além de desktops. As falhas afetam:

  • servidores corporativos
  • ambientes em nuvem
  • clusters Kubernetes
  • dispositivos IoT

As vulnerabilidades estão presentes desde o kernel 4.11, lançado em 2017 — ou seja, quase uma década de exposição silenciosa.

A descoberta foi feita pela Qualys, que utilizou sua plataforma de gestão de ativos para estimar o número de sistemas afetados.

Risco estratégico

Especialistas apontam que o tipo de exploração possibilitado pelo CrackArmor é compatível com operações conduzidas por grupos patrocinados por estados, especialmente aqueles focados em sabotagem de infraestrutura crítica.

Órgãos como a CISA e o Departamento de Segurança Interna dos Estados Unidos já emitiram alertas para setores como energia, saúde, água e defesa.

Correções e recomendações

A Qualys desenvolveu provas de conceito demonstrando os ataques, mas optou por não divulgar o código para evitar abusos.

A divulgação foi feita de forma coordenada com equipes responsáveis por distribuições Linux e ferramentas críticas, incluindo mantenedores do sudo. Até o momento, as falhas ainda não receberam identificadores CVE, pois o processo depende da integração das correções ao kernel estável.

As recomendações principais incluem:

  • aplicar atualizações de kernel assim que disponíveis
  • mapear sistemas potencialmente vulneráveis
  • monitorar alterações no diretório do AppArmor
  • reforçar a segurança em ambientes com contêineres

Existe uma ironia técnica aqui que beira o filosófico: o AppArmor foi criado para limitar o poder dos programas… e acabou, por um detalhe de implementação, permitindo exatamente o oposto. Segurança em computação não falha por falta de boas ideias — falha nos cantos invisíveis onde implementação e suposição se encontram. E é justamente nesses cantos que os atacantes vivem.