Menemukan 0-day jarak jauh dengan memanfaatkan o3 pada implementasi SMB di Linux

• Berbagi pengalaman menemukan kerentanan 0-day jarak jauh (CVE-2025-37899) pada implementasi SMB di kernel Linux dengan memanfaatkan model OpenAI o3
• Saat melakukan benchmark kemampuan analisis LLM terhadap kode ksmbd, dilakukan eksperimen perbandingan performa LLM dengan menjadikan kerentanan yang sebelumnya ditemukan secara manual sebagai acuan
• Dalam proses pendeteksian kerentanan, konteks disusun per fungsi dan diberikan prompt yang sesuai agar o3 dapat mengenali kerentanannya
• Hasil eksperimen menunjukkan o3 menemukan kerentanan dengan akurasi 2–3 kali lebih tinggi dibanding LLM sebelumnya, sekaligus secara otomatis menemukan bentuk baru bug use-after-free
• LLM, khususnya model terbaru seperti o3, menunjukkan fleksibilitas dan kreativitas yang mirip pendekatan manusia dalam audit kode dan riset kerentanan, sehingga nilainya untuk penggunaan praktis makin tinggi

---

Pendahuluan

Tulisan ini memperkenalkan bagaimana model OpenAI o3 digunakan untuk menemukan kerentanan 0-day jarak jauh pada implementasi SMB (ksmbd) di kernel Linux. Eksperimen dilakukan hanya dengan memanfaatkan API o3, tanpa framework atau alat tambahan. ksmbd adalah server yang mengimplementasikan protokol SMB3 di dalam kernel Linux untuk menangani berbagi file melalui jaringan. Audit kerentanan ini bermula sebagai selingan dari pengembangan terkait LLM, lalu dijadikan benchmark untuk mengukur seberapa baik o3 dapat menemukan bug nyata. Fokus utama di sini adalah kerentanan zero-day CVE-2025-37899 yang ditemukan oleh o3.

Kerentanan ini merupakan masalah use-after-free yang terjadi dalam proses penanganan perintah SMB logoff. Masalah ini menuntut pemahaman tentang situasi koneksi bersamaan ke server dan cara objek tertentu dibagikan di antara beberapa thread. o3 mendeteksi kerentanan ini dengan memahami isu konkurensi semacam itu serta kesalahan pengelolaan objek dalam konteksnya. Ini merupakan kasus publik pertama di mana LLM menemukan jenis kerentanan seperti ini.

Pesan utamanya adalah bahwa melalui o3, kemampuan analisis kode dan penalaran logis LLM telah melompat ke tingkat berikutnya, dan para peneliti kerentanan perlu benar-benar memperhatikan arah perkembangan ini. LLM tidak menggantikan pakar, tetapi sudah berkembang menjadi alat yang secara drastis meningkatkan produktivitas dan efisiensi pakar. Untuk kode di bawah 10 ribu baris, o3 dapat memberikan bantuan yang nyata dalam menemukan dan menyelesaikan sebagian besar masalah.

Benchmark o3 dengan memanfaatkan CVE-2025-37778

Latar belakang dan tujuan benchmark

Pertama, kemampuan deteksi kerentanan o3 dievaluasi dengan menjadikan CVE-2025-37778 yang ditemukan secara manual (selanjutnya disebut kerentanan autentikasi Kerberos) sebagai tolok ukur. Ini adalah masalah use-after-free yang terjadi ketika status sesi memenuhi kondisi tertentu selama proses autentikasi klien.

• Saat status sesi adalah SMB2_SESSION_VALID, objek pengguna dibebaskan dari memori
• Jika autentikasi kemudian gagal, objek pengguna tidak diinisialisasi ulang dan tetap dapat diakses dalam kondisi itu, sehingga terjadi use-after-free
• Untuk memahami seluruh jalur terkait, perlu menelusuri sekitar 3.300 baris kode, sehingga ini menjadi tugas benchmark dengan tingkat kesulitan yang sesuai

Penyusunan konteks analisis

Dalam eksperimen ini, konteks (area kode) yang diberikan ke LLM disusun dengan cermat dari sudut pandang sistem deteksi kerentanan otomatis yang nyata. Berdasarkan unit handler perintah SMB, fungsi utama dan fungsi turunannya hingga kedalaman pemanggilan 3 level dimasukkan agar seluruh kode yang saling terkait secara logis ikut terinput (total 3,3k LoC, sekitar 27k token). Fungsi terkait seperti parsing data, percabangan permintaan, dan pemutusan koneksi juga perlu disertakan agar hasilnya cukup andal.

Prompt spesifik dan materi input yang digunakan dapat dilihat di repositori Github terkait. Kepada LLM diberikan kondisi berikut:

• Diberi instruksi yang jelas untuk mendeteksi kerentanan use-after-free
• Dijelaskan secara singkat struktur dasar ksmbd dan threat model-nya
• Digunakan prompt pengarah untuk mencegah false positive

Query aktual dijalankan berulang menggunakan alat baris perintah llm untuk mengumpulkan hasil eksperimen (N=100).

Hasil eksperimen benchmark

• o3 : dari 100 kali, mendeteksi kerentanan autentikasi Kerberos 8 kali, gagal mendeteksi 66 kali, dan melaporkan false positive 28 kali
• Claude Sonnet 3.7 : hanya mendeteksi 3 kali
• Claude Sonnet 3.5 : gagal mendeteksi dalam 100 percobaan

Pada akhirnya, o3 mencatat akurasi 2–3 kali lebih tinggi dibanding LLM sebelumnya. Selain itu, keluaran o3 secara nyata ringkas seperti laporan ringkasan yang ditulis peneliti keamanan manusia. Sebaliknya, hasil Sonnet 3.7 memberi kesan lebih mirip log kerja yang berfokus pada proses, dengan kelebihan dan kekurangan masing-masing.

Penemuan 0-day nyata (CVE-2025-37899) melalui o3

Eksperimen pada lingkungan input kode berskala besar

Selain kerentanan Kerberos, dilakukan juga upaya pendeteksian kerentanan menyeluruh dengan o3, termasuk seluruh handler perintah SMB (sekitar 9.000 baris). Berbagai handler, kode koneksi/pemutusan, dan bagian lain digabung sehingga total sekitar 12k LoC (sekitar 100 ribu token) dimasukkan sekaligus. Saat dijalankan 100 kali, kerentanan autentikasi Kerberos hanya terdeteksi 1 kali, sehingga penurunan performa terlihat jelas, tetapi tujuan utamanya adalah menguji sejauh mana LLM dapat dimanfaatkan pada cakupan kode yang lebih luas.

Kerentanan baru yang ditemukan dalam eksperimen ini

Di tengah proses itu, ditemukan bug use-after-free baru yang dideteksi o3 selain masalah autentikasi Kerberos. Bug tersebut berada pada handler logoff sesi, berupa masalah konkurensi ketika dua thread dalam kondisi koneksi bersamaan berbagi/mengakses objek user milik sesi, lalu satu thread membebaskan objek itu sementara thread lain tetap merujuknya.

Ringkasan laporan kerentanan otomatis dari o3

• Dua worker thread bekerja bersama: satu membebaskan objek user dari memori saat melakukan pelepasan sesi (logoff), sementara yang lain terus memakai objek user itu pada sesi yang sudah ada
• Jika dereference terjadi dari jalur lain segera setelah objek dibebaskan (sebelum diinisialisasi ke NULL), maka terjadilah classic use-after-free
• Bergantung pada timing, DoS akibat NULL dereference juga dapat terjadi
• Ini dapat berujung pada korupsi memori kernel dan eksekusi kode arbitrer

Insight yang diperoleh dari laporan otomatis

Dari laporan otomatis ini, disadari bahwa cara perbaikan pada kerentanan autentikasi Kerberos yang sudah ada (mengatur ke NULL segera setelah pembebasan) bukan solusi mendasar untuk penanganan logoff. Artinya, keamanan hanya dapat dijamin jika mempertimbangkan binding sesi dan vektor serangan antarthread. Dalam sejumlah laporannya, o3 juga mampu menangkap poin ini dan membuktikan bahwa ia dapat mengusulkan perbaikan yang “lebih kuat”.

Kesimpulan

LLM, khususnya model terbaru seperti o3, menunjukkan performa yang jauh lebih dekat dengan peneliti keamanan manusia dibanding teknik sebelumnya dalam analisis kode yang kreatif dan fleksibel. Sampai belakangan ini, kemungkinan tersebut lebih sering dibicarakan secara teoretis, tetapi o3 adalah yang pertama mencapai tingkat yang secara nyata berguna dalam praktik pada kasus riil. Tentu saja o3 masih memiliki kemungkinan false positive dan miss, tetapi peluangnya untuk benar-benar menghasilkan keluaran yang berguna kini cukup tinggi sehingga layak dipakai dalam pekerjaan nyata. Kini saatnya peneliti kerentanan dan pengembang mencari cara untuk menggabungkan LLM secara efisien ke dalam alur kerja mereka.

[GN⁺]

Komentar Hacker News

• Penulis menjelaskan bahwa ia mengelola proyek dengan menyusun system prompt, informasi latar, perintah bantu, dan sebagainya masing-masing dalam file .prompt terpisah, lalu menjalankannya lewat llm
  Saya merasa cara memanfaatkan LLM yang begitu terstruktur ini menunjukkan bahwa, layaknya alat rekayasa lain, pendekatan tersebut memerlukan pemikiran desain yang cermat dan penyesuaian spesifikasi yang teliti
  Proyek terkait bisa dilihat di sini

  • Menariknya, saya merasa lucu bahwa penulis dengan jujur mengakui soal bagian itu dengan mengatakan, "sebenarnya seluruh system prompt saya berbasis tebakan, dan jauh dari sains maupun engineering"

  • Ada berbagai cara menulis prompt, tetapi tidak ada tolok ukur yang layak untuk benar-benar mengevaluasi atau membandingkannya, jadi rasanya seperti melafalkan mantra secara improvisasi
    Misalnya instruksi seperti "kamu adalah ahli pencarian kerentanan", "beri tahu hanya kerentanan yang nyata, bukan yang palsu", atau memisahkannya dengan tag HTML acak yang diduga direspons baik oleh model
    Saya jadi bertanya-tanya, sebenarnya unsur engineering itu masuk di bagian mana

  • Menarik rasanya melihat prinsip engineering dibawa untuk mencoba mengendalikan sistem yang pada dasarnya tidak stabil dan tak dapat diprediksi
    Prompt seperti ini rasanya lebih tepat disebut sebagai 'petunjuk'
    Semua LLM saat ini sering mengabaikan prompt di bawah tujuan dasarnya untuk tetap memberikan jawaban (terlepas benar atau tidak), bahkan jika prompt-nya kontradiktif

• Disebutkan dalam tulisan itu bahwa rasio signal-to-noise sekitar 1:50, tetapi saya pikir penulis bisa memilih signal yang bermakna dengan baik karena ia sangat memahami codebase tersebut
  Bagian ini, yaitu otomatisasi dalam membedakan signal yang bermakna, menurut saya adalah potensi besar nyata yang bisa diperoleh dari pemanfaatan LLM, jadi saya akan mengikuti perkembangannya dengan minat besar

  • Kami sedang mengembangkan sistem untuk memperbaiki masalah rasio signal-to-noise ini, dan juga sedang langsung membandingkan beberapa software agent yang belakangan populer
    Variasi hasilnya sangat besar, dan kami berencana mempublikasikan semua hasil eksperimen dalam konferensi yang akan segera datang
    Sepertinya itu akan memberi gambaran menyeluruh tentang tren terbaru di industri

  • Beberapa hari lalu saya terpikir, mungkinkah memanfaatkan seluruh sejarah yang ada di Linux kernel, seperti semua perubahan git, mailing list, dan sebagainya, lalu mengembangkannya menjadi model fine-tune
    Saya berharap LLM seperti itu bisa menjadi versi sintetis yang lebih mendekati intuisi pengembang yang benar-benar telah lama menangani kodenya
    Banyak hal juga bisa tercakup hanya dengan high context length, dan beberapa codebase bahkan melebihi 200 ribu token hanya dari kodenya sendiri, jadi saya rasa ada peluang

  • Rasio 1:50 adalah tingkat deteksi yang sangat bagus dalam situasi seperti 'mencari jarum di tumpukan jerami'

  • Jika LLM bisa langsung menulis harness dan proof-of-concept test untuk membuktikan setiap dugaan kerentanan, saya perkirakan rasio signal-to-noise akan membaik drastis
    Sayangnya, otomatisasi seperti itu saat ini masih cukup mahal

• Hal yang paling mengesankan bagi saya adalah fakta bahwa penulis sendiri mengulang pencarian kerentanan 100 kali untuk tiap model LLM
  Tingkat investasi sumber daya seperti ini jauh lebih tinggi dibanding kebanyakan masalah yang selama ini saya tangani dengan LLM, jadi sekarang saya juga mulai berpikir apakah saya perlu menyerahkan satu putaran 'pengulangan brutal' kepada model

  • Pada akhirnya, kesimpulannya adalah butuh banyak uang

  • Kerentanan zero-day bisa dijual dengan harga besar, dan juga bisa menghasilkan uang lewat bug bounty
    Biaya penggunaan LLM sangat kecil dibanding imbalan seperti itu
    Lingkungan keamanan di masa depan, ketika biaya inferensi mendekati nol, kemungkinan akan terlihat sangat berbeda

  • Menjalankannya 100 kali per model juga berarti konsumsi energinya cukup besar
    Saat satu kerentanan yang umum muncul di kode berbasis C ditemukan dengan penggunaan sumber daya sebesar ini, maknanya terasa memudar, dan yang justru menonjol adalah kesan pemborosan dan kemewahan
    Mengingat saat ini kita sedang berada dalam krisis iklim global, saya tak bisa tidak khawatir melihat sumber daya terus dibakar untuk hal-hal yang tak terlalu bernilai, seperti pada era 1950-an

• Karena Claude tidak diberi scratchpad (ruang untuk merangkum pemikiran antara), saya rasa hasilnya jadi mencampur alur pikir dengan laporannya
  Saya ingin bereksperimen melihat seberapa berbeda Claude jika secara resmi diizinkan memiliki ruang untuk merapikan pikirannya
  Sementara o3 menyampaikan inti secara rapi seperti bug report yang ditulis manusia, hasil Sonnet 3.7 terasa masih menyisakan alur seperti isi kepala atau log kerja, dalam konteks yang sama

  • Saya sendiri sudah memakai langsung o3, 3.7, dan Gemini 2.5 pro, dan kesan saya o3 berada di level yang tak bisa dibandingkan
    Skor benchmark mungkin tidak tampak sangat besar, tetapi makin kompleks tugasnya, makin besar arti perbedaan itu
    Saya penasaran kenapa diumumkan sejak November tahun lalu tetapi baru dirilis sekitar sebulan lalu (mungkin demi keamanan), dan saya juga menantikan o4

  • Saya penasaran apakah ada yang bisa merekomendasikan contoh penggunaan, paper penelitian, atau tautan terkait "scratchpad" dalam riset

• Saya suka bagian yang sangat merangkum esensi proses prompt engineering ini
  Terutama kalimat seperti "saya sudah berusaha sebaik mungkin memberi panduan agar false positive tidak menandai kerentanan yang salah, tetapi saya tidak punya cara untuk tahu apakah ini benar-benar membantu dan hanya bisa berharap demikian, saya juga belum cukup mengevaluasi apakah ini efektif, jadi ini bukan sains maupun engineering, hasil evaluasinya akan saya bagikan nanti" terasa sangat mirip dengan alur saya sendiri saat mengembangkan prompt

• Saya berpikir mungkin inilah use case yang paling cocok untuk LLM, yaitu di bidang seperti ini (deteksi kerentanan otomatis)
  Secara teori, seluruh proses bisa diotomatisasi, dan LLM bisa diperlakukan seperti fuzzer yang sangat maju: target dijalankan terus di VM, lalu ketika anomali terdeteksi, kemungkinan kerentanan nyata dapat diidentifikasi
  (Ingat bahwa banyak exploit awal pada dasarnya bermula dari menjatuhkan mesin atau memicu crash lalu disempurnakan)
  Pemanfaatan LLM seperti ini memang tampak sangat efektif, tetapi di sisi lain juga membawa implikasi bahwa "hanya karena kita bisa melakukan pengujian seperti ini bukan berarti ada sesuatu yang sangat baru atau menentukan yang terungkap"

• Saya meninggalkan tautan YouTube ke materi presentasi saya sendiri tentang topik penargetan otomatis bug zk (terkait zero-knowledge proof)

  • Saya membagikan sekali lagi tautan bersih untuk video YouTube di atas tanpa parameter pelacakan
    Parameter tambahannya bisa dianggap hanya untuk pelacakan tautan

• Saya sungguh berharap ini tidak berakhir seperti isu yang terus bermunculan di curl
  Untuk konteks terkait, lihat tulisan Daniel Stenberg

• Setahu saya, ksmbd dikenal sebagai server SMB di kernel space yang menargetkan bobot ringan dan performa tinggi dibanding server Samba tradisional
  Q1: Saya penasaran siapa yang benar-benar memakai ksmbd di lingkungan produksi
  Q2: Saya penasaran apa alasannya

  • 1. Saya rasa pengguna yang mewakili adalah mereka yang sebelumnya memakai server SMB bawaan kernel di Solaris atau Windows

2. Performa Samba tertinggal cukup jauh dibanding itu, sehingga bahkan pada 2025 masih banyak orang menjalankan Windows sebagai server file sharing
   Adakah yang tahu apakah ini mendukung ACL secara native seperti di Windows?
   (Itu adalah alasan terakhir saya tetap menjalankan Solaris, dan setahu saya hal itu didukung lewat ZFS)
   Samba masih terjebak pada struktur kuno seperti sinkronisasi UID/GID Unix dan model keamanannya
   Server SMB di kernel juga punya trade-off yang jelas, karena di Windows pernah ada kerentanan remote root serius yang benar-benar terjadi

• Penyebabnya adalah masalah lisensi
  Samba berlisensi GPLv3, sedangkan Linux hanya bisa memakai GPLv2

• Saya menduga orang memakainya semata karena ringan dan berperforma tinggi

• Saya rasa alasannya mirip dengan memakai kmod-trelay alih-alih relayd

• Saya pikir tantangan terbesar jangka pendek LLM (Alignment Problem) justru terlihat pada otomatisasi kerentanan seperti ini
  Baru-baru ini saya menemukan kerentanan keamanan yang sangat serius di server niche yang kadang saya gunakan, hampir tanpa usaha berkat LLM
  Jika pasar ini menjadi otomatis, saya khawatir berbagai perangkat lunak long tail yang dulu tidak cukup bernilai untuk dibobol secara manual akan mulai dihantam masalah serius dalam jumlah besar

  • Di sisi lain, berkat kemajuan teknologi seperti ini, kita juga bisa menganalisis codebase kita sendiri secara otomatis dari 'sudut pandang adversarial'
    Kerentanan yang tadinya mungkin ditemukan peneliti dan kemudian diserang bisa lebih dulu kita tambal secara proaktif
    Jadi rasanya kurang tepat jika ini disebut sebagai masalah alignment

  • Penyerang memang bisa mengotomatisasi pencarian kerentanan, tetapi pihak bertahan juga bisa memiliki kemampuan yang sama
    Bahkan otomatisasi pertahanan bisa disusun untuk setiap build atau proses persetujuan commit