CVE-2026-31431 (Copy Fail) – Ferramentas de Mitigação Técnica

1. Visão geral

Este pacote fornece uma solução automatizada para detectar e mitigar a vulnerabilidade CVE-2026-31431 (também conhecida como Copy Fail) em sistemas Linux com kernels afetados (versões 4.14 a 6.12.84, 6.13 a 6.18.21, etc.).

As ferramentas consistem em:

Um script Bash unificado (mitigate_copyfail.sh) que:
- Executa Phalanx-CCS (verificação ativa da superfície de ataque) e Silent4Labs (avaliação de risco).
- Detecta a configuração do kernel (CONFIG_CRYPTO_USER_API_AEAD=m|y).
- Aplica a mitigação apropriada:
  - Módulo carregável (=m): cria /etc/modprobe.d/disable-algif-aead.conf com install algif_aead /bin/false e descarrega o módulo (rmmod).
  - Módulo embutido (=y): adiciona o parâmetro de inicialização do kernel initcall_blacklist=algif_aead_init (requer reinicialização).
- Verifica o estado final e extrai a pontuação e o nível de risco do Silent4Labs.
Um playbook Ansible (mitigation.yml) que:
- Copia os scripts para os servidores remotos.
- Executa o script de mitigação e captura sua saída.
- Remove códigos de cor ANSI.
- Analisa o status final do Phalanx e os valores do Silent4Labs.
- Exibe um resumo legível por humanos e salva um log detalhado na máquina de controle.

Nota importante: A mitigação é temporária. A correção permanente é atualizar o kernel para uma versão que inclua o patch a664bf3d603d (≥6.18.22, ≥6.19.12 ou ≥7.0).

2. Requisitos

2.1. Máquina de controle (onde o Ansible é executado)

Ansible 2.9 ou superior
Python 3.6 ou superior
Acesso SSH aos servidores alvo (com become: yes)

2.2. Servidores remotos

Bash 4+
Python 3 (para Phalanx-CCS)
Privilégios sudo (para aplicar a mitigação)
Kernel afetado (opcional; se o kernel já estiver corrigido, o script não fará alterações)

Os scripts de detecção (Phalanx-CCS e Silent4Labs) são seguros e não exploram a vulnerabilidade; eles apenas verificam a superfície de ataque.

3. Estrutura do repositório

cve-2026-31431-mitigation/
├── README.md
├── scripts/
│   ├── mitigate_copyfail.sh      # Script unificado (detecção + mitigação)
│   ├── check_copyfail.py         # Phalanx-CCS (verificador de acessibilidade)
│   └── check-copyfail.sh         # Silent4Labs (avaliação de risco)
├── ansible/
│   ├── ansible.cfg               # (opcional) Configuração do Ansible
│   ├── inventory.ini             # Inventário de servidores
│   └── mitigation.yml            # Playbook principal
└── resultados_cve/               # Pasta gerada automaticamente para logs

4. Instalação e configuração

4.1. Clonar o repositório

git clone https://github.com/your-username/cve-2026-31431-mitigation.git
cd cve-2026-31431-mitigation/ansible

4.2. Preparar o inventário (`inventory.ini`)

Exemplo para um servidor remoto:

[servers]
server1 ansible_host=192.168.1.10 ansible_user=root

[localhost]
localhost ansible_connection=local

[all:vars]
ansible_become=yes
# ansible_become_password=my_password  # se usar senha para sudo

4.3. Verificar caminhos dos scripts

Em mitigation.yml, a tarefa Copy scripts to remote usa src: "../scripts/{{ item }}". Certifique-se de que o caminho relativo está correto ou modifique-o conforme sua estrutura.

5. Execução

A partir do diretório ansible/:

ansible-playbook -i inventory.ini mitigation.yml -k -K

-k solicita a senha SSH.
-K solicita a senha become (sudo).

Ao usar localhost com ansible_connection=local, não é necessário SSH.

5.1. Saída esperada

O playbook exibe um resumo em texto simples semelhante a:

==========================================
RESULTADOS DA MITIGAÇÃO
==========================================
Host: server1
------------------------------------------
  - Status: SISTEMA SEGURO
  - Código: (não aplicável)
------------------------------------------
  - Pontuação final: 40 / 100
  - Nível de risco: MÉDIO
==========================================

Além disso, um arquivo de log é salvo em resultados_cve/<hostname>_mitigation.log contendo a saída completa do script (data, versão do kernel, mensagens de detecção, etc.).

6. Modo de depuração

Se os valores extraídos mostrarem ? ou Não detectado, habilite as tarefas de depuração em mitigation.yml:

Altere when: false para when: true nas três tarefas DEBUG (ou defina when: true para visualizar clean_stdout e saídas de regex).
Execute novamente o playbook e observe a saída para ajustar os padrões de busca, se necessário.

7. Personalização

7.1. Alterar o diretório de logs

Edite as tarefas Create local results directory e Save full output to local file:

path: /absolute/path/resultados_cve
dest: "/absolute/path/resultados_cve/{{ inventory_hostname }}_mitigation.log"

7.2. Desabilitar cópia de scripts (se já estiverem presentes)

Comente as tarefas de cópia e ajuste o caminho na tarefa Run mitigation script para apontar para o local existente.

7.3. Limpar automaticamente scripts remotos

Altere when: false para when: true na última tarefa (Clean up remote scripts).

8. Limitações e avisos

A mitigação via parâmetro de inicialização (initcall_blacklist) requer uma reinicialização para ter efeito. O playbook não reinicia automaticamente; uma janela de manutenção deve ser planejada.
Em sistemas com CONFIG_CRYPTO_USER_API_AEAD=y (kernel embutido), o módulo não pode ser descarregado com rmmod; a única forma é o parâmetro de inicialização.
A pontuação do Silent4Labs é indicativa; um valor médio (ex.: 40/100) não significa que o sistema é explorável se a mitigação estiver ativa.
Os scripts de detecção podem precisar de privilégios para ler /proc/crypto e /boot/config-*; eles são executados com become: yes.

9. Referências

10. Licença

Este projeto é distribuído sob a licença MIT. Scripts de terceiros (Phalanx-CCS, Silent4Labs) mantêm suas respectivas licenças.

Apoie o projeto

Se você achar esta ferramenta útil, por favor, considere dar uma estrela no GitHub!

cve-2026-31431-mitigation

Mais Populares