Nove vulnerabilidades de confused deputy no módulo AppArmor do núcleo Linux afetam sistemas desde a versão 4.11 e permitem manipulação de perfis, criação de namespaces de usuário com capacidade ampliada, negação de serviço e quebra de garantias de isolamento.
| Componente | Módulo AppArmor do núcleo Linux, mecanismo de controle de acesso obrigatório usado para aplicar perfis de segurança a processos e serviços. |
| Vetor | Usuários locais sem privilégio podem explorar falhas de confused deputy por meio de interações com pseudoarquivos, perfis AppArmor, namespaces de usuário e ferramentas privilegiadas como Sudo e Postfix. |
| Impacto | Escalada local para root, contorno de restrições de namespace de usuário, enfraquecimento do isolamento de contêineres, negação de serviço por esgotamento de pilha e leitura fora dos limites com exposição de informações úteis contra KASLR. |
| Prioridade | Aplicar correções do núcleo Linux nos sistemas que usam AppArmor, priorizando hosts multiusuário, servidores de contêineres e distribuições com AppArmor habilitado por padrão. |
| Versões | O problema afeta núcleos Linux desde a versão 4.11 em distribuições que integram AppArmor; o AppArmor está no núcleo principal desde a versão 2.6.36. |
| Artefatos | A classe de falhas foi agrupada sob o nome CrackArmor e não tinha identificadores CVE atribuídos no momento da publicação original. |
CrackArmor reúne nove vulnerabilidades no AppArmor, módulo de segurança do núcleo Linux usado para aplicar controle de acesso obrigatório a processos, serviços e aplicações. A classe descrita é de confused deputy: um usuário que não tem permissão direta para executar determinada ação consegue induzir um componente mais privilegiado a agir em seu favor, abusando da confiança atribuída a esse componente. Nesse caso, o efeito prático se concentra na manipulação de perfis de segurança, no contorno de restrições de namespace de usuário e na quebra de garantias que deveriam limitar processos confinados.
O impacto confirmado é local, mas crítico para ambientes compartilhados e para infraestrutura com contêineres. Um usuário sem privilégio pode chegar à escalada para root por combinações complexas envolvendo o AppArmor e ferramentas como Sudo e Postfix, além de acionar negação de serviço por esgotamento de pilha. A mesma família de problemas também inclui leitura fora dos limites capaz de expor informação útil contra KASLR, mecanismo que dificulta a previsibilidade de endereços no núcleo. A presença dessas falhas desde 2017 amplia a janela de exposição em distribuições que adotam AppArmor como camada de confinamento.
O ponto central da exploração está na diferença entre a intenção da política de segurança e a forma como perfis AppArmor podem ser manipulados por caminhos indiretos. AppArmor restringe programas por perfis que definem quais arquivos, recursos e operações são permitidos ou negados. Quando um componente privilegiado interpreta ou aplica uma política sob influência de um usuário não autorizado, a decisão de segurança deixa de refletir apenas o limite esperado do processo confinado. Esse descompasso permite que a política seja enfraquecida, substituída por regras adversas ou usada para provocar falhas de disponibilidade.
A manipulação de pseudoarquivos e perfis permite cenários em que proteções de serviços críticos são desabilitadas ou transformadas em políticas de negação total. A primeira consequência reduz o isolamento e abre caminho para ações que o perfil deveria bloquear. A segunda pode interromper serviços ao impedir operações essenciais. Em paralelo, a interação com parsing de perfis no nível do núcleo amplia o impacto: o usuário local contorna restrições de namespace de usuário e cria namespaces com capacidades que a distribuição pretendia limitar por meio do AppArmor.
Essa capacidade de criar namespaces de usuário plenamente capazes é especialmente sensível em sistemas Ubuntu, Debian e SUSE quando AppArmor é parte das garantias de hardening. Namespaces normalmente separam visões de recursos como processos, usuários e montagens, mas sua criação sem o controle esperado pode fornecer uma base para exploração local mais avançada. O problema também compromete o isolamento de contêineres porque a barreira entre processo confinado e host passa a depender de uma política que pode ser alterada ou contornada por um usuário local sem privilégio.
As falhas também abrangem condições de negação de serviço e exposição de memória. O esgotamento de pilha pode derrubar um caminho do núcleo ou afetar a disponibilidade de serviços dependentes da política aplicada. A leitura fora dos limites não deve ser tratada como comprometimento amplo de dados, mas como vazamento técnico de informações de memória que pode reduzir a efetividade do KASLR. Em uma cadeia maior, esse tipo de informação pode servir como etapa auxiliar para outros exploits, desde que existam vulnerabilidades adicionais e precondições compatíveis.
A superfície inclui núcleos Linux desde a versão 4.11 em qualquer distribuição que integre AppArmor. O risco é maior quando AppArmor está habilitado por padrão e é usado para restringir serviços, workloads em contêineres, aplicações de terceiros ou ferramentas administrativas. Hosts com múltiplos usuários locais, servidores que executam contêineres e ambientes em que usuários não privilegiados conseguem interagir com namespaces merecem prioridade porque o vetor não depende de acesso remoto inicial descrito no material disponível; ele depende de execução local sem privilégio.
A exposição também atinge modelos de defesa que tratam AppArmor como camada compensatória contra falhas de aplicações. Se o perfil puder ser manipulado ou se as restrições de namespace puderem ser contornadas, controles de menor privilégio, isolamento por contêiner e hardening de serviços deixam de entregar a garantia esperada. Isso não significa que todo contêiner esteja automaticamente comprometido, mas indica que o host precisa ser avaliado como parte da superfície, especialmente quando workloads permitem execução de código por usuários, jobs, pipelines ou serviços com contexto local limitado.
- Distribuições Linux com AppArmor integrado e habilitado por padrão, incluindo ambientes baseados em Ubuntu, Debian e SUSE.
- Hosts que permitem usuários locais sem privilégio, workloads multiusuário, shells restritos, jobs de automação ou execução controlada de aplicações.
- Servidores de contêineres que dependem de AppArmor para reforçar isolamento, menor privilégio e políticas de serviço.
- Sistemas em que perfis AppArmor protegem serviços como Sudo, Postfix ou outros componentes privilegiados sujeitos a interação indireta.
A investigação deve partir de sinais locais porque o vetor descrito exige presença ou execução no host. Eventos de auditoria do AppArmor, logs do núcleo e registros de criação de namespaces devem ser correlacionados com identidade de usuário, processo pai, perfil carregado e alterações inesperadas de política. Mudanças em perfis, negações súbitas contra serviços antes funcionais e permissões que deixam de ser aplicadas de forma previsível são sinais de que o controle de acesso obrigatório pode ter sido manipulado.
Em contêineres, a defesa deve comparar o perfil esperado com o perfil efetivamente aplicado aos processos em execução. Workloads que passam a criar namespaces, invocar ferramentas privilegiadas ou gerar falhas de AppArmor fora do padrão normal do serviço precisam de análise. Para casos envolvendo leitura fora dos limites e KASLR, a telemetria pode ser menos direta; o foco prático deve ser procurar crashes, mensagens anômalas do núcleo, padrões de tentativa repetida e eventos de auditoria associados a parsing ou aplicação de perfis.
Sinais envolvendo Sudo, Postfix e arquivos sensíveis devem ser tratados como alto risco quando aparecem próximos de eventos AppArmor incomuns. O material disponível menciona a possibilidade de adulteração de credenciais por modificação de etc/passwd como consequência de escalada local bem-sucedida; portanto, alterações nesse arquivo, mudanças de propriedade, permissões incomuns e contas recém-criadas devem ser revisadas em conjunto com os eventos de segurança do núcleo. A ausência de prova de conceito pública no momento da divulgação não elimina a necessidade de hunting, porque a classe de falha afeta um componente de segurança de base.
- Eventos de auditoria AppArmor indicando carregamento, alteração, negação total ou comportamento inesperado de perfis.
- Criação anômala de namespaces de usuário por contas sem privilégio ou por processos que normalmente não executam esse fluxo.
- Falhas, mensagens do núcleo ou reinicializações de serviços correlacionadas a parsing de perfis ou esgotamento de pilha.
- Interações incomuns com Sudo, Postfix e arquivos de conta do sistema próximas a eventos AppArmor suspeitos.
- Divergência entre perfis AppArmor esperados para contêineres e perfis efetivamente aplicados aos processos em execução.
A resposta principal é atualizar o núcleo Linux para uma versão corrigida pelo fornecedor da distribuição. Como as falhas residem no caminho de aplicação e parsing de política do AppArmor no núcleo, mitigação operacional temporária não oferece a mesma garantia que restaurar o código corrigido. A priorização deve começar por hosts com AppArmor habilitado, servidores com contêineres, sistemas multiusuário, ambientes de CI/CD com execução local de jobs e máquinas em que usuários não privilegiados possam acionar ferramentas privilegiadas.
Até a aplicação da correção, a equipe deve reduzir exposição local e revisar quem consegue executar código no host. Contas sem necessidade operacional devem ser desabilitadas, workloads de baixa confiança devem ser isolados em hosts corrigidos primeiro e mudanças em perfis AppArmor devem ser controladas por processo formal. Em ambientes com contêineres, a validação deve incluir reinício planejado de workloads após atualização do núcleo, confirmação de que os perfis esperados foram reaplicados e revisão de qualquer exceção criada como contorno temporário.
Depois do patch, a verificação precisa confirmar a versão efetiva do núcleo em execução, não apenas a instalação de pacotes. Sistemas que exigem reinicialização continuam expostos até carregarem o núcleo corrigido. Também é necessário revisar logs anteriores à correção para identificar exploração ou tentativas de manipulação de política, principalmente em hosts com sinais de instabilidade, falhas de serviço ou alterações de conta. Como a exploração pública foi retida para reduzir exposição, a janela inicial favorece defesa baseada em atualização, inventário preciso e telemetria local.
- Inventariar hosts com AppArmor ativo e cruzar a lista com a versão do núcleo Linux em execução.
- Aplicar atualizações de núcleo fornecidas pela distribuição e reiniciar os sistemas quando necessário para carregar o código corrigido.
- Priorizar hosts multiusuário, infraestrutura de contêineres e sistemas com workloads de baixa confiança.
- Revisar alterações recentes em perfis AppArmor, eventos de namespace de usuário e falhas de serviços protegidos.
- Validar após a correção se contêineres e serviços voltaram a operar com os perfis AppArmor esperados.
0 Comentários