DaemonSet para mitigação da vulnerabilidade CVE-2026-64564 (SCTPhantom)

Breve descrição:

SCTPhantom é um use-after-free no subsistema SCTP Dynamic Address Reconfiguration (ASCONF, RFC 5061) do kernel Linux que permite a um usuário local não privilegiado obter privilégios de superusuário (root).

A causa raiz é uma divergência de identidades no processamento do chunk ASCONF: a verificação da operação DEL-IP é feita contra o endereço de origem do pacote IPv4 (S), enquanto o processamento posterior usa o transport selecionado via Address Parameter (L). Por causa disso, a sequência ordenada

passa na verificação e remove transport(L), após o que a operação wildcard DEL-IP 0.0.0.0 reutiliza o ponteiro já liberado como um "caminho persistente". Como resultado, asoc->peer.primary_path e asoc->peer.active_path permanecem como ponteiros pendentes para o struct sctp_transport liberado, e a chamada subsequente a getsockopt(SCTP_STATUS) os desreferencia.

A lógica vulnerável foi introduzida no Linux 2.6.25 (ano de 2007, commit 42e30bf3463c), ou seja, está presente no kernel há cerca de 18 anos.

Ataque:

• não requer acesso remoto — apenas uma conta local não privilegiada
• não requer CAP_NET_ADMIN nem CAP_SYS_ADMIN, funciona com o perfil seccomp padrão ativo; ASCONF e AUTH são habilitados por socket via SCTP_ASCONF_SUPPORTED / SCTP_AUTH_SUPPORTED, portanto não é necessário alterar o sysctl net.sctp.addip_enable
• é um primitivo funcional de escape de contêiner para o host: os autores obtiveram host-root em 6 de 8 tentativas; o passo final é call_usermodehelper_exec(), que executa um processo nos initial namespaces do host
• em caso de exploração mal-sucedida, encerra "limpo", sem kernel panic, o que dificulta a detecção
• a cadeia do exploit reutiliza código existente do kernel (commit_creds() orientado a dados), sem shellcode e sem ROP clássico

Tecnologias afetadas:

• Kernel Linux, subsistema net/sctp (módulo sctp), processamento de ASCONF em net/sctp/sm_make_chunk.c
• Módulo sctp_diag (depende de sctp), usado para inspeção de sockets SCTP

A vulnerabilidade só é explorável se o SCTP estiver disponível: se o módulo sctp não estiver carregado e seu carregamento automático estiver bloqueado, o vetor fica indisponível.

Alvos confirmados pelos autores (root obtido):

Versões corrigidas do kernel:

Kernels de fornecedores podem conter um backport do fix mesmo com uma versão mais antiga na string de versão — a versão do kernel em si não é um indicador suficiente de vulnerabilidade; baseie-se no advisory ou nos fontes do fornecedor.

Vetor de ataque e nível de gravidade de acordo com o CVSS v.4.0:

Pontuação base: 8.5 (HIGH)

Vetor: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

O que este fix faz

O DaemonSet, automaticamente, em cada worker node do cluster:

1. Verifica o estado dos módulos — verifica se sctp e sctp_diag estão carregados e com qual refcnt. A verificação é intencionalmente passiva: o DaemonSet não abre socket SCTP antes de aplicar a blacklist, para não provocar o carregamento automático do módulo em um nó onde ele ainda não está carregado
2. Verifica se o SCTP está em uso no nó — analisa o refcnt do módulo e as entradas ativas em /proc/net/sctp/assocs e /proc/net/sctp/eps. O próprio Kubernetes não usa SCTP, mas cargas de trabalho do usuário podem declarar protocol: SCTP em Service/Pod
3. Bloqueia os módulos vulneráveis — cria /etc/modprobe.d/blacklist-sctp.conf com regras install e blacklist para sctp e sctp_diag
4. Descarrega os módulos — executa rmmod para sctp_diag e depois para sctp (a ordem é importante: sctp_diag depende de sctp). Se forem detectadas conexões SCTP ativas, o descarregamento é ignorado, a menos que FORCE_APPLY=true seja definido explicitamente
5. Verifica a mitigação — confirma a presença da configuração, que modprobe sctp é rejeitado e que a criação de socket SCTP (socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)) não passa mais
6. Monitora o estado — a cada hora verifica a presença da configuração, restaura-a caso desapareça e descarrega novamente os módulos se eles forem carregados de novo

Importante: dois resultados possíveis no nó

A mitigação consiste em duas partes independentes, e em parte dos nós apenas uma delas é aplicada.

1. Blacklist (aplicada sempre, de forma confiável). Após a criação de /etc/modprobe.d/blacklist-sctp.conf, o módulo sctp não pode mais ser carregado — nem automaticamente ao chamar socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP), nem por modprobe explícito. Isso fecha o vetor em nós onde o módulo ainda não foi carregado (estado típico: o SCTP não é usado pelo Kubernetes e só é carregado sob demanda).

2. Descarregamento do módulo da memória (nem sempre possível). Se o sctp já estiver carregado, na maioria dos casos não será possível descarregá-lo. Em nós testados do Yandex Managed Kubernetes (Ubuntu 22.04, kernel 5.15.0-181-generic), o módulo sctp recém-carregado e não utilizado por ninguém já apresenta refcnt=6 com lista de holders vazia e /proc/net/sctp/{assocs,eps} vazios, e o rmmod retorna ERROR: Module sctp is in use. O contador não diminui com o tempo.

Daí duas consequências:

• refcnt não é um indicador de uso do SCTP — o DaemonSet o exibe apenas de forma informativa, e a decisão de descarregar é tomada com base nas entradas ativas em /proc/net/sctp/assocs e /proc/net/sctp/eps
• em um nó onde o sctp já está residente, o DaemonSet reporta honestamente ⚠ mitigation applied PARTIALLY. A blacklist já está aplicada ali (após a reinicialização, o módulo não voltará), mas até a reinicialização o nó permanece vulnerável. Para fechar completamente o vetor, esses nós precisam ser reiniciados ou a node group precisa ser recriada

Para encontrar esses nós após a implantação:

Compatibilidade com cargas de trabalho

Importante: a mitigação desativa completamente o SCTP no nó.

O Kubernetes e os plugins de rede (Cilium, Calico) não usam SCTP para o próprio funcionamento, portanto, para a grande maioria dos clusters, a mitigação é segura. No entanto, se houver no cluster alguma carga de trabalho que use SCTP (por exemplo, aplicações de telecom, VoIP/sinalização SS7/Diameter, Service ou NetworkPolicy com protocol: SCTP), o tráfego dela deixará de funcionar.

Antes de implantar, verifique se existem esses objetos no cluster:

Se o SCTP estiver em uso no nó, o DaemonSet, por padrão, não descarrega o módulo da memória, apenas aplica a blacklist (o módulo não voltará após a reinicialização do nó) e escreve um aviso nos logs. Para descarregar à força, interrompendo as conexões SCTP existentes, defina no manifesto:

Início rápido

1. Baixar o DaemonSet

Ou clonar o repositório:

2. Aplicar o fix

3. Verificar o status da aplicação

4. Visualizar os logs da aplicação do fix

5. Encontrar nós onde a mitigação não foi aplicada completamente

Exemplo de aplicação bem-sucedida

Exemplo de aplicação parcial (o módulo já estava carregado)

Esse nó precisa ser reiniciado: a blacklist já impedirá que o módulo seja carregado novamente.

Verificando a eficácia da mitigação a partir de um pod

A verificação mais demonstrativa é reproduzir a posição do atacante: um pod não privilegiado com capabilities removidas, como na cadeia de container escape.

Saída esperada em um nó protegido:

Em um nó não protegido, a saída será SCTP REACHABLE -> EXPLOITABLE, e a própria verificação provocará o carregamento automático do módulo sctp nesse nó (depois disso, provavelmente não será mais possível descarregá-lo — veja a seção acima). Não execute isso em nós não protegidos sem necessidade.

Verificação manual da vulnerabilidade

Você pode verificar o estado do nó manualmente. Conecte-se ao nó via SSH e execute:

Atenção: executar essa verificação em um nó onde o módulo ainda não está carregado fará com que ele seja carregado automaticamente. Execute-a somente após aplicar a mitigação ou de forma consciente.

Verificar a configuração:

Verificar se os módulos vulneráveis não estão carregados:

Aplicação fora do Kubernetes

Se for necessário aplicar a mitigação em hosts comuns, use o one-liner:

Removendo o fix

Se for necessário remover o DaemonSet:

Importante: remover o DaemonSet não removerá os arquivos de configuração dos nós. O arquivo /etc/modprobe.d/blacklist-sctp.conf permanecerá no lugar e continuará protegendo o sistema.

Para remover completamente o fix dos nós, é necessário conectar-se a cada nó via SSH e remover o arquivo manualmente:

Detalhes técnicos

Permissões utilizadas:

• hostPID: true — para acessar os processos do host via nsenter
• privileged: true — para gravar em /etc e descarregar módulos do kernel
• Volume mount / — para acesso ao filesystem do host

Imagem: ubuntu:22.04

Recursos:

• Init container: 10m CPU / 64Mi RAM (requests), 200m CPU / 128Mi RAM (limits)
• Monitor container: 5m CPU / 32Mi RAM (requests), 50m CPU / 64Mi RAM (limits)

Namespace: kube-system

Por que o config contém tanto install quanto blacklist: o blacklist bloqueia o carregamento por alias (incluindo o carregamento automático ao chamar socket(..., IPPROTO_SCTP)), mas não impede um modprobe sctp explícito. A linha install sctp /bin/false fecha também esse caminho.

Por que a mitigação não substitui a atualização do kernel: o bloqueio do módulo elimina o vetor, mas o bug em si permanece no kernel. A solução definitiva é atualizar o kernel para uma versão corrigida (veja a tabela acima) ou atualizar as imagens dos nós e recriar a node group.

Compatibilidade

• ✓ Yandex Managed Kubernetes
• ✓ Ubuntu 20.04
• ✓ Ubuntu 22.04
• ✓ Kubernetes 1.20+

Licença

Apache License 2.0

Consulte LICENSE para obter detalhes.

Suporte

Em caso de problemas, abra uma issue no repositório.