Menemukan 0-day jarak jauh di implementasi SMB Linux menggunakan o3

 (sean.heelan.io)
2 poin oleh GN⁺ 2025-05-25 | 1 komentar | Bagikan ke WhatsApp
  • Dalam audit ksmbd, implementasi server SMB3 di kernel Linux, ditemukan kerentanan use-after-free jarak jauh CVE-2025-37899 hanya dengan OpenAI o3 API, tanpa framework agen atau penggunaan alat tambahan
  • Kerentanan ini adalah masalah ketika thread lain masih bisa terus mengakses sess->user yang sudah dibebaskan saat pemrosesan perintah SMB logoff; masalah ini baru terlihat jika koneksi paralel dan status berbagi sesi dilihat bersama
  • Dalam benchmark yang memakai CVE-2025-37778, yang sebelumnya ditemukan secara manual, sebagai acuan, o3 menemukan kerentanan itu 8 kali dari 100 percobaan; Claude Sonnet 3.7 menemukannya 3 kali, dan Claude Sonnet 3.5 0 kali
  • Pada kondisi 12k LoC / 100k token input, dengan input diperluas ke semua handler perintah SMB dan kode penanganan koneksi, tingkat penemuan kerentanan lama turun menjadi 1 dari 100 percobaan, tetapi dari hasil yang sama muncul kerentanan baru CVE-2025-37899
  • False positive dan keluaran yang tidak bermakna masih banyak, tetapi peluang munculnya jawaban benar sudah meningkat cukup tinggi sehingga layak ditinjau dan diverifikasi manusia dalam riset kerentanan nyata

Eksperimen menemukan kerentanan ksmbd dengan o3

  • Target audit adalah ksmbd, implementasi berbagi file protokol SMB3 di ruang kernel Linux
  • Model OpenAI o3 dipanggil melalui o3 API, tanpa scaffolding, framework agen, atau penggunaan alat tambahan
  • Kerentanan yang ditemukan adalah CVE-2025-37899, dan perbaikannya ada di commit kernel Linux
  • Masalah intinya adalah use-after-free pada handler perintah SMB logoff, dengan struktur di mana objek tanpa reference count dibebaskan saat masih dapat diakses dari thread lain
  • Kerentanan ini hanya bisa ditemukan dengan memahami koneksi paralel ke server dan objek yang dibagikan dalam situasi tertentu secara bersamaan
  • Terdapat penilaian bahwa, di antara kasus yang telah dibahas secara publik, ini tampaknya merupakan kasus pertama LLM menemukan kerentanan dengan karakter seperti ini

Kerentanan acuan CVE-2025-37778

  • CVE-2025-37778, yang terlebih dahulu ditemukan secara manual, digunakan sebagai benchmark untuk menilai performa o3
  • Kerentanan ini adalah use-after-free yang terjadi saat memproses permintaan session setup dari klien jarak jauh pada jalur autentikasi Kerberos
  • krb5_authenticate membebaskan sess->user jika sess->state == SMB2_SESSION_VALID
  • Kode setelahnya bergantung pada asumsi bahwa ksmbd_krb5_authenticate akan menginisialisasi ulangnya dengan nilai valid baru, atau bahwa setelah pengembalian -EINVAL, sess->user tidak akan digunakan
  • Dalam praktiknya, ksmbd_krb5_authenticate dapat dibuat tidak menginisialisasi ulang sess->user, dan akses ke sess->user tetap mungkin meski krb5_authenticate mengembalikan -EINVAL

Susunan benchmark dan prompt

  • CVE-2025-37778 digunakan sebagai benchmark karena berada di permukaan serangan jarak jauh, dan membutuhkan penilaian atas semua hal berikut: pemicu kondisi sess->state == SMB2_SESSION_VALID, jalur yang tidak melakukan re-inisialisasi, serta jalur akses setelah pembebasan
  • Kode minimum yang dibutuhkan untuk menjelaskan jalur kerentanan dihitung sekitar 3.3k LoC
  • Input eksperimen mencakup handler perintah session setup dan fungsi-fungsi yang dipanggil handler ini hingga kedalaman panggilan 3
  • Kode penerimaan paket, parsing permintaan, pemilihan handler perintah, serta pembersihan koneksi setelah handler selesai juga dimasukkan untuk mengurangi spekulasi tentang cara struktur data diinisialisasi
  • Input akhir sekitar 3.3k LoC / 27k token, dan file yang dianalisis dipublikasikan sebagai session_setup_code.prompt
  • Prompt memuat kondisi berikut
    • Menginstruksikan untuk mencari kerentanan use-after-free
    • Memberikan gambaran tingkat tinggi tentang peran, arsitektur, dan threat model ksmbd
    • Sangat mendorong preferensi untuk tidak melaporkan daripada melaporkan false positive
  • File prompt lengkap tersedia di repositori o3_finds_cve-2025-37899
  • Eksekusi menggunakan alat llm buatan Simon Willison

Hasil benchmark CVE-2025-37778

  • Harness eksperimen menjalankan kueri yang sama 100 kali dan menyimpan hasilnya
  • o3 menemukan CVE-2025-37778 8 kali dari 100 percobaan
  • Dalam 66 kali dari 100 percobaan, o3 menilai tidak ada bug sehingga menjadi false negative
  • 28 kali sisanya adalah false positive
  • Hasil perbandingannya sebagai berikut
    • Claude Sonnet 3.7: menemukan 3 kali dari 100 percobaan
    • Claude Sonnet 3.5: menemukan 0 kali dari 100 percobaan
  • Pada benchmark ini, o3 menunjukkan hasil yang 2–3 kali lebih baik daripada Claude Sonnet 3.7
  • Contoh laporan dipublikasikan sebagai hasil o3 dan hasil Sonnet 3.7
  • Keluaran o3, karena struktur dan fokusnya, terbaca seperti laporan bug ringkas yang ditulis manusia, meski terkadang terlalu singkat sehingga kurang jelas
  • Keluaran Sonnet 3.7 muncul dalam bentuk yang lebih mirip alur pemikiran atau log kerja

Eksperimen yang diperluas ke semua handler perintah

  • Pada eksperimen berikutnya, bukan hanya handler session setup, tetapi kode semua handler perintah SMB diberikan ke o3
  • Handler perintah berada di smb2pdu.c, dengan ukuran file sekitar 9k LoC
  • Jika semua handler, kode setup dan pembersihan koneksi, serta rutin dispatch handler perintah digabungkan, totalnya sekitar 12k LoC / 100k token input
  • Dalam kondisi ini pun eksperimen dijalankan 100 kali
  • o3 hanya menemukan kerentanan autentikasi Kerberos lama CVE-2025-37778 1 kali dari 100 percobaan, dan penurunan performa akibat bertambahnya jumlah token input terlihat jelas
  • Dalam kumpulan hasil yang sama, ditemukan laporan tentang kerentanan baru yang sebelumnya tidak diketahui, yaitu CVE-2025-37899

Jalur rentan CVE-2025-37899

  • Kerentanan baru ini juga terkait dengan pembebasan sess->user, tetapi kali ini terjadi di handler session logoff
  • smb2_session_logoff bekerja dengan urutan berikut
    • Memanggil ksmbd_close_session_fds(work)
    • Memanggil ksmbd_conn_wait_idle(conn)
    • Mengatur status sesi menjadi SMB2_SESSION_EXPIRED
    • Jika sess->user ada, membebaskannya dengan ksmbd_free_user(sess->user) lalu mengatur sess->user = NULL
  • Skenario kerentanan dalam laporan o3 adalah sebagai berikut
    • Pada SMB 3.0 atau lebih baru, transport kedua di-bind ke sesi yang sudah ada dan conn->binding == true
    • Worker-A memproses permintaan biasa seperti WRITE pada koneksi lain C2
    • smb2_check_user_session() menyimpan pointer struct ksmbd_session yang sudah ada ke work->sess dan menaikkan reference count sesi, tetapi tidak mengambil referensi terpisah untuk sess->user
    • Worker-B memproses SMB2 LOGOFF untuk sesi yang sama pada koneksi pertama C1 dan menjalankan smb2_session_logoff()
    • ksmbd_conn_wait_idle(conn) hanya menunggu permintaan yang sedang berjalan pada koneksi tersebut, tidak ikut menunggu permintaan pada koneksi lain yang memakai sesi yang sama
    • Worker-A terus berjalan dan dapat melakukan akses seperti user_guest(sess->user), ksmbd_compare_user(sess->user, …), atau sess->user->uid
  • Bergantung pada timing, ini bisa menjadi use-after-free yang menunjuk ke objek slab yang sudah dibebaskan, atau menjadi DoS berupa NULL dereference jika dibaca setelah sess->user = NULL

Perbaikan yang salah dan nilai hasil o3

  • Perbaikan yang pertama kali diusulkan untuk CVE-2025-37778 adalah menambahkan sess->user = NULL setelah ksmbd_free_user(sess->user)
  • Setelah membaca laporan CVE-2025-37899, terungkap bahwa perbaikan ini tidak memadai
  • Handler logoff memang sudah melakukan sess->user = NULL, tetapi protokol SMB dapat mengikat dua koneksi berbeda ke sesi yang sama sehingga tetap rentan
  • Pada jalur autentikasi Kerberos pun, thread lain dapat mengakses sess->user pada jendela singkat tepat setelah sess->user dibebaskan dan sebelum disetel ke NULL
  • Sebagian laporan o3 membuat kesalahan yang sama, tetapi sebagian lainnya menangkap bahwa sess->user = NULL saja tidak cukup karena adanya kemungkinan session binding
  • Keterbatasannya adalah, karena rasio true positive terhadap false positive cukup tinggi, tidak pasti apakah semua laporan telah ditinjau dengan cukup cermat

Posisi praktis dalam riset kerentanan

  • Dalam hal kreativitas, fleksibilitas, dan generalitas, LLM berada di posisi yang lebih dekat dengan auditor kode manusia dibandingkan teknik analisis program yang sudah ada
  • Sebagai pembanding disebutkan symbolic execution, abstract interpretation, dan fuzzing
  • Sejak GPT-4, kemungkinan penggunaan LLM dalam riset kerentanan memang ada, tetapi pada masalah nyata hasilnya belum sesuai harapan
  • o3 bekerja cukup baik dalam penalaran kode, tanya jawab, pemrograman, dan pemecahan masalah sehingga dapat meningkatkan performa peneliti kerentanan nyata
  • Tetap saja, o3 belum sempurna dan sangat mungkin menghasilkan keluaran tidak bermakna yang membuat pengguna frustrasi
  • Perbedaannya adalah, untuk pertama kalinya, peluang munculnya jawaban benar dinilai sudah cukup tinggi untuk dicoba pada masalah nyata

Bacaan terkait

1 komentar

 
GN⁺ 2025-05-25
Komentar Hacker News

  • Ini bagian kecil, tetapi cara penulis menyusun proyek tampak berguna. Ia membuat prompt sistem, informasi latar belakang, dan instruksi tambahan masing-masing sebagai file .prompt [1], lalu menjalankannya dengan llm
    Ini menunjukkan bahwa pemanfaatan LLM yang baik, seperti alat rekayasa lainnya, membutuhkan pola pikir engineering yang sistematis, berpusat pada spesifikasi yang matang, dan menyeimbangkan batasan desain dengan cermat
    [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899

    • Menarik jika ditafsirkan begitu, karena penulis justru mengakui bahwa bagian itu ia lakukan hanya berdasarkan intuisi

      In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering

    • Saya tidak tahu bagaimana membenchmark metodologi yang berbeda-beda seperti ini
      Semuanya terlihat seperti mantra berbasis intuisi. Frasa seperti “Anda adalah pakar penemuan kerentanan”, “Laporkan hanya kerentanan nyata tanpa false positive”, atau cara merapikan dengan tag HTML palsu karena model entah kenapa tampaknya menyukainya. Saya tidak tahu bagian mana yang bisa disebut engineering di sini
    • Menarik melihat upaya menerapkan prinsip engineering pada sistem yang pada dasarnya tidak stabil dan tidak dapat diprediksi untuk mendapatkan rasa kendali
      Prompt seperti itu seharusnya disebut petunjuk, bukan instruksi. Semua LLM saat ini akan mengabaikan prompt jika prompt tersebut bertentangan dengan satu tujuan utamanya, yaitu menghasilkan jawaban, benar ataupun tidak
    • Fakta menariknya, jika bertanya kepada LLM tentang praktik terbaik penyusunan prompt, ia akan memberi petunjuk ke arah seperti ini
      Meminta LLM membantu menulis prompt juga ternyata sangat efektif. Semua potongan prompt saya juga dirancang dengan bantuan LLM
      Secara pribadi saya menyimpan semuanya dalam file org-mode dan menyalin-tempelkannya ke percakapan ChatGPT saat diperlukan. Saya lebih suka interaksi yang lebih “berbentuk diskusi”, tetapi pendekatannya sama
    • Pada akhirnya intinya adalah kerapian: https://taoofmac.com/space/blog/2025/05/13/2230

  • Artikel itu menyebut rasio sinyal terhadap noise sekitar 1:50. Penulis sangat mengenal codebase ini, jadi berada dalam posisi yang baik untuk memilah sinyal dari noise
    Hasil yang benar-benar menarik akan muncul dari otomatisasi bagian ini, jadi saya akan terus mengamatinya

    • Selama beberapa tahun saya membuat beberapa soal wawancara take-home, dirancang singkat dan mudah bagi developer berpengalaman tetapi sulit jika tidak menguasai bahasanya. Semuanya adalah masalah nyata dari pekerjaan yang saya sederhanakan menjadi bentuk minimal
      Setiap kali LLM frontier baru muncul, dengan mengecualikan model yang menggunakan input sebagai data pelatihan, saya menjalankan soal-soal wawancara itu. Saya terkejut karena proporsi jawaban yang berjalan pada percobaan pertama terus bertahan di sekitar 1:10, dan sering kali perlu lebih dari 10 putaran dorongan agar model menemukan kesalahannya sendiri
      Jadi rasio sinyal terhadap noise seperti ini pada topik yang lebih rumit terasa masuk akal
    • Saya sedang membangun sistem yang sangat meningkatkan rasio sinyal terhadap noise dalam deteksi bug, sekaligus telah melakukan benchmark menyeluruh terhadap berbagai agen perangkat lunak terkenal
      Rentang hasilnya cukup lebar, dan semuanya akan saya ungkap dalam presentasi konferensi yang akan datang, jadi pantas dinantikan. Ini akan cukup menggambarkan kondisi terkini bidang ini
      Sunting: redaksinya membingungkan
    • Beberapa waktu lalu saya terpikir, mungkin bisa dilakukan semacam fine-tuning terhadap semua perubahan git, mailing list, dan sebagainya dari kernel Linux
      LLM seperti itu mungkin akan menjadi versi sintetis yang mirip seseorang yang telah bertahun-tahun bekerja pada codebase tersebut dan mempelajari berbagai karakteristiknya
      Memang bisa memasukkan sangat banyak hal ke konteks panjang, tetapi beberapa codebase dari kodenya saja sudah 200 ribu token, jadi saya tidak yakin
    • Otomatisasi bagian ini sepertinya sederhana. Secara umum, LLM yang punya kemampuan semantik X untuk menjalankan suatu tugas biasanya punya kemampuan lebih besar daripada X untuk menentukan jawaban terbaik di antara N jawaban untuk tugas yang sama
      Terutama jika menggunakan metode turnamen biner seperti RAInk yang muncul di sini beberapa minggu lalu, dan ada juga cara memakai konsensus antar-LLM yang berbeda. Saya heran Gemini 2.5 PRO tidak dipakai di sini; menurut pengalaman saya, itulah LLM terkuat untuk pekerjaan semacam ini
    • 1:50 adalah rasio deteksi yang sangat bagus untuk mencari jarum dalam tumpukan jerami

  • Bagian paling menarik dan penting dari artikel ini bagi saya adalah bahwa penulis menjalankan pencarian kerentanan 100 kali untuk setiap model
    Itu jauh lebih banyak daripada jumlah komputasi yang biasanya ingin saya gunakan untuk sebagian besar masalah yang pernah saya coba dengan model bahasa besar, tetapi mungkin memang model harus terus dijalankan saja

    • Saya baru sadar ini tidak saya tulis di artikel, tetapi kalau penasaran, menjalankan versi 100 ribu token sebanyak 100 kali memakan biaya sekitar 116 dolar AS
    • Zero-day bisa dijual dengan harga besar, dan bug bounty pun bisa menghasilkan uang. Biaya LLM mungkin hanya setetes air dalam ember dibandingkan itu
      Saya tidak tahu seperti apa dunia keamanan siber ketika biaya inferensi mendekati nol, tetapi ruangnya akan menjadi sangat berbeda dari sekarang
    • Cukup punya banyak uang saja~
    • “100 kali per model” berarti konsumsi energi yang cukup besar. Pencapaian menemukan kerentanan paling umum di codebase berbasis C pun jadi terlihat kurang mengesankan
      Ini malah lebih dekat dengan merayakan kemewahan dan pemborosan. Kita sedang menghadapi perubahan iklim global, tetapi tetap membakar sumber daya untuk hal-hal sepele seolah-olah masih tahun 1950-an

  • Entah sangat beruntung, atau seperti dugaan, Gemini 2.5 PRO tampaknya lebih mudah menemukan kerentanan ini. Tingkat keberhasilannya tinggi, jadi cukup menjalankan prompt berikut beberapa kali: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...

  • Belakangan pola seperti ini terus berulang
    Jika ada masalah dengan definisi yang jelas dan fungsi evaluasi, biarkan LLM memperkecil ruang solusi. LLM sangat kuat dalam merekonstruksi pola, dan bisa bekerja baik jika jawabannya memiliki pola yang mirip dengan sesuatu yang sudah dikenal sebelumnya
    Dalam kasus ini, masalahnya adalah jenis kerentanan keamanan tertentu, dan evaluatornya adalah pakar. Skalanya berbeda, tetapi secara mental mirip dengan upaya-upaya terbaru menggunakan LLM untuk optimasi genetik
    “Mathematical discoveries from program search with large language models” juga bacaan yang menarik, dan seingat saya dulu pernah muncul di HN
    https://www.nature.com/articles/s41586-023-06924-6
    Namun, secara pribadi saya merasa agak berlebihan jika hanya dari eksperimen ini disimpulkan bahwa LLM melakukan penalaran terhadap kode

  • Saya berharap ini benar-benar nyata, dan bukan sesuatu seperti yang terus terjadi pada curl
    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • Saya tidak yakin dengan klaim bahwa ini kerentanan pertama yang ditemukan dengan LLM. Misalnya OSS-Fuzz [0] menemukan beberapa kasus lewat fuzzing, dan Big Sleep juga menemukannya dengan pendekatan agen [1]
    [0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
    [1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...

    • Jelas bukan kerentanan pertama yang ditemukan dengan LLM =) Mungkin saya seharusnya menulisnya dengan lebih jelas
      Yang dimaksud dalam tulisan itu adalah “untuk memahami kerentanan ini, perlu menalar koneksi simultan ke server dan bagaimana beberapa objek dibagikan dalam situasi tertentu. o3 memahami hal ini dan menemukan lokasi sebuah objek tertentu yang tidak dihitung referensinya dibebaskan sementara masih dapat diakses dari thread lain. Sepengetahuan saya, ini adalah diskusi publik pertama tentang LLM yang menemukan kerentanan dengan karakter seperti ini”
      Yang ingin saya katakan adalah, sepengetahuan saya ini dokumentasi publik pertama tentang LLM yang menemukan bug semacam itu, yakni bug yang berasal dari jumlah kode yang tidak sepele dan akses bersamaan ke resource bersama. Setidaknya bagi saya, ini penanda menarik dari perkembangan LLM

  • Mengingat nilai dari penemuan zero-day, jika bisa ditemukan secara andal hanya dengan beberapa ratus panggilan API, hampir semua badan intelijen di dunia akan menggelontorkan uang ke sini
    Apalagi jika model bisa di-fine-tune dengan banyak contoh, dan saya rasa pihak seperti OpenAI tidak akan menyediakan hal semacam itu lewat API publik

    • Benar. Karena rekayasa seputar kontrol output, yaitu penyensoran, dan ketentuan penggunaan, muncul insentif untuk mengarahkan model agar menemukan bug yang mungkin ada, tetapi tidak mengizinkan hasilnya
      Bagi badan pemerintah atau organisasi lain, pembatasan seperti ini tentu bukan masalah. Ini hanya berlaku untuk semua pihak lainnya. Jadi orang-orang akan memakai model dan agen lain yang tidak memiliki pembatasan semacam ini
      Aman untuk berasumsi bahwa ada banyak kerentanan di berbagai perangkat lunak penting. Sekarang kerentanan-kerentanan itu bisa ditemukan. Situasi ketika game theory perlombaan senjata berlaku pada keamanan komputer dan peretasan akan mulai terjadi. Kemungkinan besar lebih cepat dari perkiraan

  • Saya tahu beberapa developer kernel telah “memverifikasi” bug ini, tetapi saya penasaran apakah ada yang benar-benar membuat dan menguji proof of concept
    Bagian sepenting ini dalam proses justru sama sekali tidak ada PoC-nya. Tanpa PoC, kita tidak tahu masalah apa yang bisa muncul di tengah jalan, sehingga tidak bisa menilai kemungkinan eksploitasi atau dampaknya. Setidaknya penulis tidak menyebutnya eksekusi kode jarak jauh tanpa verifikasi
    Namun bagaimana jika ada satu kepingan puzzle yang terlewat oleh penulis dan para developer, atau diasumsikan sudah ditangani o3 padahal sebenarnya berada di luar konteks o3, lalu hal itu membuat kerentanan ini sendiri menjadi tidak valid?
    Saya tidak mengatakan bahwa hal seperti itu ada, dan saya juga tidak akan meluangkan waktu untuk mengerjakan bagian penulis. Namun laporan ini belum sepenuhnya diverifikasi, dan mengingat potensinya menjadi tulisan blog berpengaruh di bidang riset kerentanan LLM ke depannya, ini terasa seperti preseden yang berbahaya
    Secara pribadi, saya merasa PoC || GTFO harus diterapkan lebih ketat dari sebelumnya pada laporan kerentanan apa pun yang dihasilkan model
    Pandangan bahwa o3 jauh lebih baik daripada model sebelumnya atau model lain yang ada saat ini tetap valid, dan metodologinya juga menarik. Saya memahami dorongan dan kebutuhan untuk menulis dengan frasa seperti itu agar orang memperhatikan hal tertentu. Inilah masalah clickbait. Namun tolong lakukan dengan lebih baik. Buat proof of concept dan verifikasi klaimnya, jangan malas. Jika menulis blog yang bisa memengaruhi cara peneliti kerentanan melakukan riset, seharusnya mendorong verifikasi, bukan asumsi teoretis. Kalau tidak, alih-alih memperdalam pemahaman sistem lewat laporan yang dapat diverifikasi dan terbukti, laporan yang keliru tetapi terdengar masuk akal justru akan menyebarkan ketidaktahuan

    • Saya penulisnya. Ya, saya membuat proof of concept. Ya, itu memicu laporan KASAN dan crash
    • Saya ingin bertanya, apakah yang Anda inginkan adalah proof of concept yang memicu crash melalui use-after-free, atau hanya akan puas dengan proof of concept eksekusi kode jarak jauh yang lengkap

  • Ada satu kutipan kecil yang indah yang dengan sempurna menangkap bagaimana sebagian besar sesi pengembangan prompt saya berjalan

    Saya mencoba mengarahkannya dengan tegas agar tidak melaporkan false positive, dan lebih memilih tidak melaporkan bug apa pun daripada melaporkan false positive. Saya tidak tahu apakah ini membantu, tetapi saya ingin ini membantu, jadi beginilah jadinya. Sebenarnya seluruh system prompt saya bersifat spekulatif karena saya belum menjalankan evaluasi dalam jumlah yang cukup untuk menentukan apakah itu membantu atau justru menghambat, jadi anggap saja ini setara dengan saya memanjatkan doa, bukan sesuatu yang menyerupai sains atau rekayasa. Setelah saya menjalankan evaluasi tersebut, saya akan memberi tahu Anda.