TL;DR

• Vulnerabilidade: Três falhas inter-relacionadas no runtime runC exploram condições de corrida em operações de montagem (mounts) para permitir Container Escape.

• Versões Afetadas: runC versões <=1.2.7, <=1.3.2, e <=1.4.0-rc.2.

• Impacto Rápido: Um atacante com privilégios baixos dentro do contêiner pode escalar privilégios para root no host, resultando em Negação de Serviço (DoS) ou execução remota de código (RCE) no host.

• Ação Imediata: Atualize o runC para 1.2.8, 1.3.3 ou 1.4.0-rc.3 (ou superior) e implemente Admission Policies para garantir o uso de User Namespaces, contêineres rootless e imagens assinadas.

Fase 1 — Entendendo a CVE

Este conjunto de vulnerabilidades (CVE-2025-31133, CVE-2025-52565 e CVE-2025-52881) afeta o runc, o componente que executa contêineres conforme a especificação OCI (Open Container Initiative). O cerne do problema reside em condições de corrida exploradas durante a fase de configuração do contêiner, especificamente ao lidar com montagens de arquivos especiais.

O bug ocorre porque o runc falha em verificar a integridade do alvo de um bind-mount em um momento crítico. Por exemplo, na CVE-2025-31133, o runc usa o /dev/null do contêiner para mascarar caminhos sensíveis do host. Se um atacante substituir o /dev/null por um symlink para um caminho controlado durante a janela de tempo da montagem, o runc realiza um bind-mount arbitrário, transformando a operação em um alvo de Montagem Arbitrária [3].

Fase 2 — Superfície de ataque e exploração

Quem pode explorar?

O ataque é local e requer que o atacante tenha privilégios baixos dentro do contêiner. Não é um ataque de rede (não-auth), mas sim um ataque de escalada de privilégios a partir de um contêiner já comprometido ou mal configurado. A exploração depende da capacidade de manipular o sistema de arquivos do contêiner durante a fase de inicialização, aproveitando a condição de corrida.

Cenários práticos em Kubernetes

Em ambientes Kubernetes, o risco é amplificado:

• Pods Privilegiados: Pods que rodam com privileged: true ou com capabilities elevadas são alvos fáceis.

• Admission Policies Fracas: A ausência de Admission Policies que restrinjam a execução de pods como root ou que permitam a escalada de privilégios aumenta a superfície de ataque.

• Movimento Lateral: Após a fuga, o atacante pode acessar o nó de Kubernetes, roubar segredos (tokens de serviço) e se mover lateralmente pela infraestrutura.

Eu uso Kubernetes “Gerenciado” também preciso me preocupar?

Sim, mas a dependência do cloud provider fornecer a atualização, porém não se esqueça que é necessário atualizar não apenas o control plane, os nodes também precisam ser atualizados.

Amazon e Google já estão cientes e liberando atualizações para seus nodes, é hora de um rollout turma!

Aqui os relatórios de cada uma delas:

AWS - https://aws.amazon.com/security/security-bulletins/rss/aws-2025-024/

GCP - https://docs.cloud.google.com/release-notes

Azure - Ainda não informou, acompanhe aqui o feed de segurança

Fase 3 — Correção e contenção

Atualize agora!

A correção definitiva é a atualização do runtime runc.

• Versões Corrigidas: runc 1.2.8, 1.3.3, e 1.4.0-rc.3 (ou superior).

• Ação: Atualize imediatamente o containerd, CRI-O ou qualquer outro componente que utilize o runc em seu ambiente. Consulte as notas de release do seu fornecedor de distribuição (Red Hat, Ubuntu, SUSE, etc.) para pacotes específicos.

Se a atualização imediata não for possível, implemente as seguintes policies de contenção:

Hardening de Contêineres (Admission Policies)

Use ValidatingAdmissionPolicy (com CEL) ou ferramentas como Kyverno/Gatekeeper para impor policies de segurança no cluster.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: runc-cve-mitigation
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE","UPDATE"]
      resources: ["pods"]
  validations:
  - expression: "has(object.spec.securityContext) && object.spec.securityContext.runAsNonRoot == true"
    message: "Pods devem rodar como não-root para mitigar a escalada de privilégios."
  - expression: "object.spec.containers.all(c, has(c.securityContext) && c.securityContext.privileged != true && c.securityContext.allowPrivilegeEscalation != true)"
    message: "Privileged e allowPrivilegeEscalation devem ser desabilitados."
  - expression: "has(object.spec.securityContext) && object.spec.securityContext.seccompProfile.type == 'RuntimeDefault'"
    message: "Seccomp Profile deve ser definido como RuntimeDefault ou mais restritivo."

NetworkPolicies

Restrinja o movimento lateral após uma potencial fuga. Uma NetworkPolicy de egress restritiva é crucial.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: my-vulnerable-app
spec:
  podSelector:
    matchLabels: { app: my-vulnerable-app }
  policyTypes: [Egress]
  # Bloqueia todo o tráfego de saída, exceto o estritamente necessário
  egress:
  - to:
    - ipBlock:
        # Permite apenas tráfego para o servidor de API (exemplo)
        cidr: 10.0.0.0/24 
    ports:
    - protocol: TCP
      port: 443

Hardening de supply chain

O assessment de risco deve incluir a origem das imagens.

Por serem o vetor do ataque, ter controle sobre suas imagens é o primeiro passo para a proteção, outras vulnerabilidades podem ser exploradas para ganhar acesso a sua aplicação e então explorar essa vulnerabilidade do runC para ganhar acesso a todo sistema.

Utilize imagens base seguras, com superfície de ataque mínima. Comece agora em app.quor.dev 

Detecção e resposta

Indicadores em logs

A exploração bem-sucedida de um container escape via core_pattern pode deixar rastros no log do host ou do runtime de contêineres, especialmente tentativas de escrita em arquivos sensíveis do /proc.

Falco: Detecção Comportamental de Container Escape

O Falco, o runtime security monitor da Sysdig, é uma ferramenta essencial para a detecção da exploração destas CVEs do runC, pois opera no nível de chamadas de sistema (syscalls) e eventos do kernel, monitorando o comportamento real dos contêineres, e não apenas assinaturas de vulnerabilidades. A exploração bem-sucedida destas falhas, que culmina em um container escape e escalada de privilégios, invariavelmente envolve ações altamente suspeitas no nível do sistema hospedeiro. Especificamente, o Falco pode ser configurado com regras para disparar alertas imediatos ao detectar tentativas de escrita em arquivos sensíveis do host, como /proc/sys/kernel/core_pattern ou /proc/sysrq-trigger, que são os alvos finais de ataque explorados pelas CVE-2025-31133 e CVE-2025-52565. Ao correlacionar a identidade do processo (que deveria estar isolado no contêiner) com a manipulação de arquivos críticos do host, o Falco fornece uma camada de defesa comportamental que transcende a necessidade de patches imediatos.

Além da detecção do ataque final, o Falco é crucial para identificar as tentativas de manipulação de arquivos de dispositivo e symlinks que precedem a escalada. Regras específicas podem monitorar o acesso ou a criação de symlinks em caminhos como /dev/null ou /dev/console por processos que não deveriam interagir com esses arquivos de forma não padrão, especialmente se o processo estiver rodando com privilégios de root dentro do contêiner. A capacidade do Falco de inspecionar o contexto do contêiner (como namespaces e capabilities) e o contexto do host simultaneamente permite que ele diferencie o comportamento legítimo do runtime da atividade maliciosa de um contêiner comprometido. Desta forma, mesmo que a CVE-2025-52881 burle as policies de segurança baseadas em labels (como SELinux/AppArmor), o Falco ainda detecta a anomalia comportamental no nível do kernel, fornecendo a visibilidade necessária para a resposta a incidentes.

Consultas Loki/LogQL

Monitore logs do runtime (containerd, crio) ou do kernel por atividades incomuns de montagem ou escrita em caminhos sensíveis.

# 1. Tentativas de escrita em arquivos procfs sensíveis (após o escape)

{job="kubelet"} |~ "write to /proc/sys/kernel/core_pattern"

# 2. Logs de segurança (auditd) indicando manipulação de symlinks em /dev

{job="auditd"} |~ "SYMLINK.*(/dev/null|/dev/console)"

Passos de resposta

1. Isolar: Isole o nó comprometido e remova todos os pods não essenciais.

2. Coletar Artefatos: Colete logs do runtime, logs do kernel e o estado do sistema de arquivos do contêiner e do host para o assessment forense.

3. Revogar Credenciais: Revogue imediatamente quaisquer ServiceAccounts ou chaves de API que o contêiner comprometido possa ter acessado.

4. Revalidar Integridade: Verifique a integridade do runc e de outros binários críticos no host.

Matriz de risco resumida

Checklist rápido

• Atualizar runC para a versão 1.2.8, 1.3.3 ou 1.4.0-rc.3 (ou superior).

• Implementar Admission Policies para impor runAsNonRoot: true.

• Implementar Admission Policies para desabilitar privileged: true e allowPrivilegeEscalation: true.

• Configurar pods para utilizar User Namespaces sempre que possível.

•  Adotar contêineres rootless como padrão de segurança.

• Revisar NetworkPolicies de egress para limitar o movimento lateral.

•  Monitorar logs de runtime e auditd para tentativas de manipulação de mounts ou escrita em /proc.
  
  

Referências

1. Ubuntu. CVE-2025-31133.: https://ubuntu.com/security/CVE-2025-31133

2. Red Hat Customer Portal. CVE-2025-52565.: https://access.redhat.com/security/cve/cve-2025-52565

3. GitHub. container escape via "masked path" abuse due to mount race conditions.: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2

4. Red Hat Customer Portal. CVE-2025-52881.: https://access.redhat.com/security/cve/cve-2025-52881