Kisah di Balik Penguatan Firefox dengan Claude Mythos Preview

• Mozilla membangun pipeline untuk menemukan bug keamanan nyata dalam skala besar di Firefox dengan meningkatkan performa model dan menyempurnakan harness guna meningkatkan sinyal serta mengurangi noise pada laporan keamanan buatan AI
• Pada rilis Firefox 150, 271 bug yang diidentifikasi oleh Claude Mythos Preview telah diperbaiki, dan perbaikan terkait juga disertakan di 149.0.2, 150.0.1, dan 150.0.2
• Bug perwakilan yang diungkap mencakup primitive objek palsu akibat penghapusan inisialisasi struct WebAssembly GC di JIT, UAF pada proses induk melalui race condition IPC, masalah deserialisasi NaN, bug rehash XSLT berusia 20 tahun, dan overflow bitfield layout 16-bit menggunakan rowspan=0
• Sebagian besar bug yang diungkap adalah pelarian sandbox, dengan asumsi proses konten yang telah dikompromikan menaikkan hak akses ke proses induk yang memiliki privilese, sehingga analisis AI dapat menjangkau permukaan serangan yang sulit ditemukan hanya dengan fuzzing
• Mozilla menambahkan harness agentic di atas infrastruktur fuzzing yang sudah ada untuk membuang dugaan yang tidak dapat direproduksi dan memverifikasi hipotesis dengan test case, serta berencana mengintegrasikannya ke continuous integration agar pemindaian dilakukan saat patch masuk ke tree

---

Perubahan dalam bug keamanan Firefox yang terungkap oleh model AI

• Hingga beberapa bulan lalu, laporan bug keamanan buatan AI yang masuk ke proyek open source sering tampak meyakinkan tetapi salah, sehingga menciptakan biaya asimetris bagi maintainer
• Di Firefox, situasinya berubah besar dalam waktu singkat, dan alasan utamanya adalah peningkatan performa model serta perbaikan teknik untuk mengarahkan, memperluas, dan menggabungkan model dengan harness guna meningkatkan sinyal dan menyaring noise
• Mozilla biasanya tetap merahasiakan laporan bug terperinci selama beberapa bulan bahkan setelah advisory keamanan dan distribusi perbaikan dirilis, tetapi kali ini memutuskan untuk membuka sebagian laporan dengan mempertimbangkan urgensi dan perhatian di seluruh ekosistem
• Laporan yang diungkap dipilih dari berbagai subsistem browser; pemilihannya agak acak, tetapi kedalaman dan keragaman laporan menunjukkan bahwa para defender perlu menerapkan teknik ini

Bug perwakilan yang diungkap

• 2024918
  • Karena pemeriksaan kesetaraan yang salah, JIT menghapus inisialisasi struct WebAssembly GC yang masih hidup sebagai optimisasi, dan ini dapat menciptakan primitive objek palsu yang berpotensi terhubung ke pembacaan dan penulisan arbitrer pada kode yang telah melalui fuzzing ekstensif oleh peneliti internal maupun eksternal
• 2024437
  • Bug berusia 15 tahun pada elemen <legend>, yang dipicu lewat kombinasi cermat edge case dari area browser yang saling berjauhan seperti batas kedalaman stack rekursif, properti expando, dan cycle collection
• 2021894
  • Race condition IPC dapat dieksploitasi secara andal sehingga proses konten yang telah dikompromikan dapat memanipulasi reference count IndexedDB pada proses induk, menimbulkan UAF dan potensi pelarian sandbox
• 2022034
  • NaN mentah dapat terlihat seperti pointer objek JS bertag saat melintasi batas IPC, sehingga deserialisasi double dapat berujung pada primitive objek palsu di proses induk dan pelarian sandbox
• 2024653
  • Test case kompleks yang menggabungkan nested event loop, listener pagehide, dan garbage collection memicu UAF pada setter properti elemen <object>
• 2022733
  • Dengan mendorong ribuan hash sertifikat ke WebTransport, race condition pada loop penyalinan dengan reference count tinggi diperbesar, lalu memicu UAF pada proses induk melalui IPC dari proses konten yang telah dikompromikan
• 2023958
  • Dengan mencegat pemanggilan fungsi DNS glibc dan mensimulasikan server DNS berbahaya, edge case fallback dari UDP ke TCP direproduksi untuk memicu pembacaan buffer berlebih dan kebocoran memori stack proses induk saat parsing HTTPS RR dan ECH
• 2025977
  • Ini adalah bug XSLT berusia 20 tahun di mana pemanggilan key() yang reentrant memicu rehash hash table dan membebaskan backing store, tetapi pointer entri mentah tetap dipakai; ini juga salah satu dari beberapa masalah XSLT sec-high yang telah diperbaiki
• 2027298
  • Setelah mem-patch color picker untuk mensimulasikan pilihan pengguna yang sulit diotomatisasi, nested event loop dijalankan lewat event input sinkron untuk masuk ulang ke actor teardown dan menyebabkan callback dibebaskan saat sedang di-unwind, sehingga memicu UAF pada proses konten
• 2023817
  • Proses konten yang telah dikompromikan dapat mengirim gambar wallpaper arbitrer untuk didekodekan oleh proses induk, dan bila digabungkan dengan kerentanan decoder gambar hipotetis dapat berujung pada pelarian sandbox
  • Diperlukan penalaran yang sulit diotomatisasi untuk menilai tingkat kepercayaan input pada proses induk
• 2029813
  • Pada RLBox, teknologi sandboxing granular Firefox 95, sandbox dapat dilewati dengan memanfaatkan celah pada logika validasi yang menyalin nilai dari sisi tak tepercaya ke sisi tepercaya
• 2026305
  • Dengan test case yang sangat kecil yang memanfaatkan makna khusus rowspan=0 pada tabel HTML, lebih dari >65535 baris ditambahkan untuk melewati clamping dan menyebabkan overflow pada bitfield layout 16-bit, dan bug ini luput dari fuzzer selama bertahun-tahun

Pelarian sandbox dan lapisan pertahanan

• Sebagian besar bug yang diungkap adalah pelarian sandbox, dan untuk berkembang menjadi kompromi rantai penuh Firefox, bug-bug ini harus digabungkan dengan exploit lain
• Laporan semacam ini mengasumsikan bahwa proses sandbox yang merender konten situs sudah lebih dulu dikompromikan oleh bug terpisah, lalu kode mesin yang dikendalikan penyerang berupaya menaikkan hak akses ke proses induk yang memiliki privilese
• Saat membuat pelarian sandbox, model dapat mem-patch source code Firefox selama kode yang dimodifikasi hanya berjalan di dalam proses sandbox
• Jenis bug ini sulit ditemukan dengan fuzzing, dan Mozilla telah mengembangkan teknik seperti IPC fuzzing with snapshots, tetapi analisis AI mampu menjangkau permukaan penting ini dengan jauh lebih menyeluruh
• Bagian yang tidak ditemukan model juga penting
  • Dalam beberapa tahun terakhir, peneliti keamanan telah mengirim beberapa laporan tentang pemicu prototype pollution pada proses induk berprivilese untuk melarikan diri dari sandbox proses
  • Alih-alih memperbaiki masalah satu per satu, Mozilla menerapkan perubahan arsitektur untuk membekukan prototype secara default
  • Dalam log harness terlihat banyak jejak percobaan jalur pelarian ini yang terhalang oleh desain, yang mengonfirmasi efek langsung dari pekerjaan hardening sebelumnya

Membangun pipeline penguatan keamanan dengan harness

• Dalam beberapa tahun terakhir, Mozilla secara internal melakukan eksperimen audit kode LLM untuk menganalisis statis kode berisiko tinggi dengan model seperti GPT 4 dan Sonnet 3.5
• Eksperimen awal menunjukkan potensi, tetapi rasio false positive terlalu tinggi sehingga sulit diperluas skalanya
• Situasi berubah dengan hadirnya harness agentic yang dapat mendeteksi masalah keamanan secara andal
  • Dapat menemukan bug nyata
  • Dapat membuang dugaan yang tidak dapat direproduksi
  • Dengan antarmuka dan instruksi yang tepat, dapat membuat serta menjalankan test case yang dapat direproduksi untuk memverifikasi hipotesis bug kode secara dinamis
• Setelah memperbaiki issue awal yang dikirim Anthropic pada Februari, Mozilla membangun harness sendiri di atas infrastruktur fuzzing yang sudah ada
• Pada awalnya, eksperimen skala kecil dimulai dengan Claude Opus 4.6 untuk mencari pelarian sandbox
  • Bahkan model ini saja sudah mengidentifikasi cukup banyak kerentanan yang sebelumnya tidak diketahui, yang memerlukan penalaran kompleks atas kode engine browser multiproses
  • Pada awalnya mereka mengamati proses langsung dari terminal sambil menyesuaikan prompt dan logika secara real time
  • Setelah operasinya stabil, pekerjaan diparalelkan ke beberapa VM ephemeral, dan tiap VM mencari bug di file target tertentu lalu mencatat hasilnya ke bucket
• Hanya menemukan subsistem saja tidak cukup
  • Perlu diintegrasikan dengan seluruh siklus hidup bug keamanan, termasuk apa yang dicari, di mana melihat, dan bagaimana menangani hasilnya
  • Ini termasuk deduplikasi terhadap issue yang ada, pelacakan bug, triage, hingga distribusi perbaikan
  • Model adalah elemen primitive inti yang menggerakkan harness, tetapi agar berguna dalam skala besar diperlukan pipeline menyeluruh
• Harness memiliki potensi untuk digunakan ulang lintas proyek, tetapi pipeline berbeda untuk tiap proyek tergantung makna codebase, alat, dan prosesnya
• Diperlukan banyak iterasi dengan loop umpan balik yang erat bersama proses para engineer Firefox menangani bug yang masuk

Claude Mythos Preview dan dampak pergantian model

• Setelah pipeline end-to-end tersedia, mengganti ke model lain saat model baru muncul menjadi hal yang sederhana
• Mozilla menemukan berbagai bug serius juga dengan model terbuka, dan berkat pipeline ini dapat langsung memanfaatkannya saat mendapat kesempatan mengevaluasi Claude Mythos Preview
• Upgrade model meningkatkan efektivitas seluruh pipeline
  • Lebih baik menemukan bug potensial
  • Lebih baik membuat test case proof-of-concept yang membuktikan bug
  • Lebih baik merangkum patologi dan dampaknya
• Selain memperbaiki 271 bug yang diidentifikasi Claude Mythos Preview pada rilis Firefox 150, perbaikan terkait juga disertakan di 149.0.2, 150.0.1, dan 150.0.2
• Secara internal, bug terus ditemukan juga dengan metode lain, dan seperti proyek lain, laporan eksternal juga meningkat tajam dalam beberapa bulan terakhir
• Semua bug memerlukan perhatian cermat agar dapat diperbaiki dengan benar, dan dalam beberapa bulan terakhir banyak pekerjaan serta jam kerja panjang dijalani untuk mengejar skala yang belum pernah terjadi sebelumnya ini
• Lebih dari 100 orang berpartisipasi memberi kontribusi kode untuk merilis Firefox yang paling aman, dan selain penulisan serta review patch, mereka juga membangun dan memperluas pipeline, melakukan triage, menguji perbaikan, dan mengelola proses rilis tiap bug

Pelajaran utama

• Siapa pun yang membuat perangkat lunak kini dapat menemukan bug dan memperkuat kode dengan model modern dan harness
• Dapat dimulai dari prompt sederhana, lalu diamati dan diiterasi
  • Prompt awal tidak jauh berbeda dari pendekatan yang ditunjukkan dalam video ini
  • Seiring iterasi, banyak orchestration dan alat ditambahkan untuk mengoptimalkan dan memperluas pipeline, tetapi inti loop internalnya adalah “temukan bug di bagian kode ini dan buat test case-nya”
• Potensi bug di Firefox belum sepenuhnya habis ditemukan, tetapi mereka puas dengan lintasan saat ini
• Pemindaian saat ini umumnya berfokus pada area kode tertentu yang ditentukan, yaitu file dan fungsi, dengan campuran penilaian manusia dan sinyal otomatis
• Dalam waktu dekat, mereka berencana mengintegrasikan analisis ini ke sistem continuous integration agar pemindaian dilakukan saat patch masuk ke tree
• Model fleksibel terhadap format konteks yang diberikan, dan pemindaian berbasis patch diperkirakan dapat bekerja setara atau bahkan lebih baik daripada pemindaian berbasis file
• Saat ini penuh risiko, tetapi juga peluang besar, dan semua pihak perlu bergerak bersama untuk membuat internet lebih aman

Pertanyaan yang sering diajukan

• Alasan angka “271 bug” berbeda dari jumlah advisory keamanan

  • Di halaman advisory keamanan, bug laporan internal dikelompokkan menjadi CVE “rollup” yang membundel beberapa bug di bawahnya
  • Halaman web tersebut dibuat dari yaml di repositori foundation-security-advisories, yang merupakan lokasi resmi penetapan CVE
  • Sebagian browser tidak membuat pengenal CVE untuk issue yang ditemukan secara internal, tetapi Mozilla mengungkapkannya agar informasi tersedia setransparan mungkin
  • Firefox 150 memiliki 3 rollup internal
    • CVE-2026-6784: 154 bug
    • CVE-2026-6785: 55 bug
    • CVE-2026-6786: 107 bug
  • Jumlah tiga rollup internal adalah 316, lebih banyak daripada 271 bug yang diumumkan ditemukan dengan Claude Mythos Preview
  • Alasannya adalah tim keamanan Mozilla menyerang Firefox setiap hari untuk menemukan bug baru, dan caranya merupakan gabungan sistem fuzzing, inspeksi manual, serta pipeline agentic baru yang memanfaatkan berbagai model
  • Pada rilis April, total 423 bug keamanan diperbaiki
    • 271 bug yang diumumkan dua minggu lalu
    • 41 bug laporan eksternal
    • 111 sisanya ditemukan secara internal dan secara kasar terbagi menjadi tiga kategori
      • Bug yang ditemukan pipeline ini menggunakan Claude Mythos Preview tetapi diperbaiki di rilis lain, bukan Firefox 150
      • Bug yang ditemukan pipeline ini menggunakan model lain
      • Bug yang ditemukan dengan teknik lain seperti fuzzing
  • Anthropic juga mendapat kredit langsung untuk 3 CVE yang terpisah dari pekerjaan terbaru ini
    • CVE-2026-6746
    • CVE-2026-6757
    • CVE-2026-6758
  • Ketiganya adalah perbaikan bug yang dikirim Anthropic Frontier Red Team ke Mozilla beberapa bulan lalu, dan masing-masing diberi CVE unik sesuai prosedur umum

• Arti peringkat tingkat keparahan keamanan

  • Mozilla menggunakan security severity ratings dari critical hingga low untuk menunjukkan tingkat urgensi bug
  • sec-critical dan sec-high diberikan pada kerentanan yang dapat dipicu oleh tindakan pengguna biasa seperti mengunjungi halaman web
  • Tidak ada perbedaan teknis antara sec-critical dan sec-high, tetapi sec-critical hanya dipakai untuk issue yang telah diungkap publik atau diketahui telah dieksploitasi dalam serangan nyata
  • sec-moderate diberikan pada kerentanan yang aslinya akan dinilai sec-high tetapi memerlukan langkah yang tidak normal dan rumit dari korban
  • sec-low diberikan pada bug yang mengganggu tetapi jauh dari membahayakan pengguna, seperti crash yang aman
  • Peringkat untuk 271 bug yang diumumkan pada Firefox 150 adalah sebagai berikut
    • sec-high 180 bug
    • sec-moderate 80 bug
    • sec-low 11 bug
  • Mozilla paling memprioritaskan bug critical/high, tetapi juga umum memprioritaskan bug keamanan moderate dan low untuk memperbaiki masalah correctness dan pertahanan berlapis

• Perbedaan sec-high atau sec-critical dengan exploit nyata

  • Bug sec-high atau sec-critical tidak otomatis berarti exploit yang praktis
  • Dalam sebagian besar kasus, satu bug critical/high saja tidak cukup untuk mengompromikan Firefox
  • Firefox memiliki arsitektur pertahanan berlapis; misalnya, bahkan jika bug JIT dieksploitasi, hasilnya biasanya hanya remote code execution di proses yang disandbox dan diisolasi per situs
  • Penyerang nyata biasanya harus merangkai beberapa exploit untuk melewati satu atau lebih lapisan sandboxing serta mitigasi tingkat OS seperti ASLR demi menaikkan hak akses
  • Mozilla umumnya tidak membuat exploit untuk memverifikasi apakah bug benar-benar bisa digunakan penyerang nyata
  • Klasifikasi sec-high didasarkan pada gejala crash yang dapat diprediksi seperti use-after-free atau masalah memori out-of-bounds yang dilaporkan oleh AddressSanitizer
  • Threat model mengasumsikan bahwa dengan upaya yang cukup, bug semacam ini mungkin dapat dieksploitasi
  • Pendekatan ini mengurangi risiko false negative dalam analisis kemungkinan eksploitasi dan memungkinkan sumber daya lebih difokuskan untuk menemukan serta memperbaiki lebih banyak kerentanan

[GN⁺]

Pendapat Hacker News

• Perlu ditegaskan lagi, bug tetaplah bug. “Potensi kerentanan” juga merupakan bug, dan kerentanan seharusnya divalidasi dampak keamanannya lewat proof of concept atau bukti setara
  Kata-kata itu penting, dan bug juga penting. Memperbaiki banyak bug sudah lama penting dan memang sudah dilakukan, dan itu sendiri sudah cukup mengesankan
  Mythos bukan berarti menulis proof of concept untuk 271 kerentanan dan membuktikan keterjangkauan jalur kode yang berdampak pada keamanan. Mythos menemukan 271 bug yang valid, dan menurut saya itu sudah cukup

  • Definisinya agak membingungkan, tetapi Mozilla membagi 271 “sesuatu” itu seperti ini [1]
    Sebagai konteks tambahan, Mozilla menerapkan tingkat keparahan keamanan dari critical sampai low untuk menunjukkan urgensi bug. sec-critical dan sec-high diberikan pada kerentanan yang bisa dipicu oleh perilaku pengguna biasa seperti mengunjungi halaman web; secara teknis keduanya tidak dibedakan, tetapi sec-critical dicadangkan untuk masalah yang sudah dipublikasikan atau diketahui dieksploitasi di dunia nyata
    sec-moderate diberikan pada kerentanan yang pada dasarnya termasuk sec-high tetapi memerlukan langkah yang tidak biasa dan rumit dari korban, dan sec-low diberikan pada bug yang mengganggu namun jauh dari merugikan pengguna, misalnya crash yang aman
    Dari 271 bug yang diumumkan di Firefox 150, 180 adalah sec-high, 80 sec-moderate, dan 11 sec-low
    Mozilla tepat di bawahnya juga mengatakan bahwa ini tidak selalu berarti eksploit praktis, tetapi tetap memakai kata “vulnerability” bahkan untuk sec-high. Di halaman definisinya, bahkan sec-low pun diklasifikasikan sebagai “vulnerabilities” [2]
    Kata adalah alat, dan kegunaannya datang dari makna kolektif. Saya penasaran dari mana kerangka makna itu diambil, apakah selaras dengan Mozilla atau berbeda
    [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
    [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
  • Mythos memang menulis proof of concept untuk semua bug yang menyebabkan crash akibat pelanggaran keamanan memori seperti use-after-free, out-of-bounds read/write
    Menurut standar kami, tanpa bukti yang menunjukkan sebaliknya, itu sudah merupakan bukti praktis yang cukup untuk menganggapnya sebagai kerentanan keamanan, dan bug hasil fuzzing memang selalu diperlakukan seperti itu
  • Claude bisa, dan memang pernah, membuat eksploit proof of concept untuk bug yang bisa dieksploitasi jika ia percaya bahwa pengguna memiliki kode tersebut
    Sumbernya hanya pengalaman pribadi, dan saya tidak bisa membagikan buktinya
  • Di lapangan, saat harus memutuskan apa yang harus ditangani lebih dulu, pembedaan seperti ini tidak terlalu berguna
  • Kalau bukan “271 PoC untuk kerentanan”, sepertinya kata yang dicari lebih dekat ke eksploit

• Tulisan blog nonteknis sebelumnya saya anggap sekadar promosi produk terang-terangan untuk Anthropic. Tulisan Mozilla Hacks yang ditautkan adalah sumber yang lebih baik daripada artikel ini dan merupakan publikasi yang menyenangkan untuk dilihat
  Sekarang tampaknya sulit menyangkal bahwa ada hasil nyata di sini. Definisi “kerentanan” internal Mozilla tampaknya dipakai lebih luas daripada yang dibayangkan banyak orang secara intuitif, tetapi bagus bahwa masalah-masalah seperti ini dianggap serius dan diperbaiki

  • https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
  • Pada saat yang sama, perusahaan lain seperti AISLE juga menemukan kerentanan yang mirip dengan Mythos memakai model yang lebih lama dan harness mereka sendiri: https://aisle.com/blog/aisle-matches-anthropic-mythos-on-fre...
    Mythos memang nyata, tetapi sepertinya pekerjaan yang sama juga bisa dilakukan dengan Deepseek pro atau GPT 5.5

• Sumber aslinya: https://news.ycombinator.com/item?id=48051079
  Ini lebih baik karena benar-benar mencantumkan sebagian laporan Bugzilla yang telah dipublikasikan. Topik ini pernah dibahas sebelumnya, tetapi bagian tentang laporan bug yang dipublikasikan itu sepenuhnya baru
  Diskusi sebelumnya ada 2 minggu lalu dengan 36 komentar: https://news.ycombinator.com/item?id=47885042

• Semoga LLM menjadi begitu bagus dalam menemukan dan memperbaiki bug sehingga para engineer Firefox bisa fokus hanya pada menambahkan fitur baru
  Ini bukan sindiran. Firefox pantas dipakai lebih luas. Kebanyakan orang di sekitar saya tidak memakai Firefox karena “Chrome melakukan hampir semuanya lebih baik”, dan Firefox kesulitan bersaing dengan roadmap browser lain

  • Saya sepenuhnya setuju bahwa Firefox harus dipakai lebih luas. Saat belanja di situs pun saya sampai memilih tempat membeli berdasarkan apakah berfungsi di Firefox
    Kadang saya juga menulis ke tim dukungan bahwa Firefox tidak didukung atau fiturnya tidak berjalan semestinya. Hampir selalu tidak ada yang terjadi, tetapi rasanya itu hal yang bisa saya lakukan untuk setidaknya menjaga browser itu tetap terlihat
  • Sebagian masalahnya adalah, kalau berhenti memperbaiki bug, Mozilla mulai melakukan hal-hal ala Mr Robot. Kami hanya ingin browser web. Tidak ada yang meminta Pocket atau AI
    Jika AI memperbaiki semua bug, selain menjaga kompatibilitas sintaks dengan berbagai bahasa build, pekerjaan apa yang tersisa? Rasanya mereka pada akhirnya akan kembali mengacaukan browser lagi
  • Saya rasa kualitas dan ketersediaan seperti itu jugalah yang membuat Chrome melaju jauh lebih cepat daripada Firefox
    Ceritanya akan berbeda jika Mozilla membuat LLM atau harness proprietari yang hanya dipakai internal dan itu membuat mereka unggul dari Chrome, tetapi itu pun tampak tidak realistis
  • Chrome tidak secara berarti lebih baik untuk lebih dari 99% use case. Saya seorang developer dan selama kira-kira 10 tahun terakhir hanya memakai Firefox dan uBlock Origin
    Istri saya juga memakai Firefox sebagai browser utama setelah saya jelaskan dan dia memahami betapa berbedanya pengalaman berinternet
    Jadi saya harap orang tidak membingkainya sebagai “monopoli itu buruk dan Google agak jahat, jadi pakailah underdog yang kurang bagus.” Untuk semua pekerjaan yang saya lemparkan kepadanya, Firefox memberi pengalaman kelas satu, dan di mobile bahkan tiga kali lebih begitu. Jauh pengalaman browser mobile yang paling berguna
  • Browser sudah lama sekali tidak membutuhkan fitur baru. Hal-hal seperti itu seharusnya menjadi ranah ekstensi

• Tiket yang ditautkan hanya beberapa, jadi mungkin saya akan berubah pikiran kalau melihat semua 271 item individual yang sebenarnya, tetapi yang saya lihat semuanya adalah bug serius di kode C++
  Firefox ditulis dalam beberapa bahasa dan C++ hanya sekitar 25%, tetapi semua masalah ini tampaknya menyentuh C++

  • Batasan umum dari pendekatan ini adalah kualitasnya hanya sebaik verifikatornya. Misalnya, hampir tidak ada yang lebih mudah diverifikasi daripada test case yang menghasilkan use-after-free dengan AddressSanitizer
    Kita perlu melihat apakah masalah yang lebih halus akan membutuhkan verifikator yang lebih spesifik, atau apakah LLM akan menjadi lebih baik dalam membayangkan kondisi risiko lain untuk diverifikasi sendiri
  • Ada kemungkinan Mythos jauh lebih baik dalam menemukan kerentanan C++ dibanding bahasa lain. Model seperti ini juga dibuat berdasarkan materi analisis keamanan yang sudah ada
    Menurut saya banyak bug ini tidak eksklusif pada C++, melainkan lebih karena kebetulan terjadi di kode C++. Bahkan Rust yang paling aman pun tidak bisa secara ajaib menangkap masalah seperti TOCTOU
  • Karena bug diverifikasi dengan AddressSanitizer, secara struktural memang hanya bug C++ yang akan ditemukan

• Membaca ini bersamaan dengan sikap orang-orang Zig yang bahkan tidak mau melihat bug buatan LLM sebagai sesuatu yang layak ditinjau membuat cara pandang saya berubah tentang teknologi apa yang akan saya masukkan ke toolchain saya ke depan

  • Keduanya benar, dan itu tergantung model apa yang dipakai serta siapa yang mengirimkan bug. Kemampuan model terdepan berubah dalam hitungan bulan dari 99% noise menjadi 99% bug valid
    Beberapa proyek dibanjiri yang pertama, jadi perlu ada pencegahan agar ini tidak menjadi serangan denial-of-service terhadap para maintainer

• Saat di PalmSource saya mencoba mendapatkan anggaran untuk alat analisis kode statis seperti CoVerity atau Fortify, tetapi jalur manajemen bilang “terlalu mahal”
  Saya menghabiskan 1 tahun lagi untuk menurunkan biaya dan membuat opsi yang dibatasi pada pemindaian network stack, lalu mereka bilang “ini berbasis BSD dan BSD pada dasarnya aman”. Keduanya tidak benar
  Pada akhirnya saya keluar dari perusahaan dan pindah ke Mozilla, dan ada komentar /* flawfinder ignore */ tersebar di seluruh kode
  Dugaan saya, Mythos hanya mengabaikan arahan flawfinder ignore dan melaporkan kerentanan yang sudah diketahui di dalam kode

  • Kodenya terbuka. Jika Anda bisa membuktikan itu benar, itu akan menjadi berita sungguhan

• Saya penasaran dampaknya pada alat analisis statis. Karakternya cukup berbeda, tetapi kadang mencapai tujuan yang sama
  Alat analisis statis bisa lambat dan menghasilkan banyak false positive. Saya penasaran apakah kalau model seperti ini menjadi cukup bagus dan murah, orang akan hampir tidak lagi melirik analisis statis

  • LLM jauh lebih baik dalam menggunakan alat daripada menggantikan alat. Biasanya jauh lebih cepat memakai alat yang sudah ada daripada mencoba mendapatkan hasil yang sama langsung dari LLM
    Memakai alat coding LLM untuk terus merapikan keluaran alat analisis statis bekerja sangat baik, dan menambahkan guardrail untuk memaksa agar masalah tidak tersisa juga ide bagus. Semacam pemeriksaan CI untuk memastikan semuanya bersih
    False positive berbeda-beda tergantung alat. Saya cenderung menghindari alat yang kebanyakan cuma menghasilkan noise, dan alat seperti itu biasanya memungkinkan aturan yang berisik dimatikan. Atau cukup suruh LLM memperbaiki semua masalah. Jika lebih murah memperbaiki daripada berdebat soal aturannya, ya tinggal perbaiki saja. Dulu itu sangat mahal karena harus dikerjakan manual oleh manusia, sekarang tidak lagi
    Saya memakai pendekatan ini saat memperbarui codebase Ansible yang tidak disentuh selama beberapa tahun. Ada ratusan masalah ansible-lint, kebanyakan peringatan deprecation dan peringatan yang tidak fatal, lalu 10 menit kemudian jumlahnya jadi 0. Mungkin bukan masalah yang sangat serius, tetapi itu tetap semacam utang teknis. Kalau saya harus memperbaiki ratusan peringatan secara manual, mungkin saya tidak akan melakukannya, tetapi kalau bisa hilang semua dengan sekali ayun tongkat sihir, tidak ada alasan untuk tidak melakukannya. Sekarang saya menyesuaikan guardrail agar ansible-lint selalu dijalankan dan masalahnya diperbaiki, dan itu hanya menambah beberapa detik
  • Kemungkinan yang menarik adalah memperkuat alat analisis statis agar bisa menemukan bentuk bug yang pertama kali ditemukan LLM[0]
    Tidak diragukan lagi alat analisis statis lebih cepat dan lebih murah, jadi lebih skalabel untuk codebase raksasa dan mungkin juga bisa menggeneralisasi metode LLM
    [0] https://lwn.net/Articles/1068968/
  • Alat analisis statis juga bisa jauh lebih cepat dan kebanyakan sepenuhnya deterministik, jadi jika dimasukkan ke CI, bug atau potensi bug bisa ditangkap sebelum masuk ke codebase
    Saya memelihara alat analisis statis yang dipakai di Firefox CI. Untuk memasukkan patch ke tree kami, Anda harus memperbaiki semuanya, baik false positive maupun true positive, atau menandainya sebagai bukan masalah. Artinya kami menoleransi 0 positive, yang merupakan standar cukup ketat
    Ini trade-off yang disadari. Agar orang tidak mengabaikannya, tidak memberi komentar penonaktifan di mana-mana, atau tidak berhenti menjalankannya sama sekali, Anda harus menaikkan rasio signal-to-noise dengan melemahkan analisis dan menerima beberapa false negative. Hampir semua alat analisis statis harus menyeimbangkan hal ini
    Sebaliknya, AI yang umum dipakai diberi ruang lebih besar. Hampir mendasar bahwa ia harus dibiarkan berhalusinasi false positive, dan justru di situlah sebagian besar kekuatannya berada. Karena itu dibutuhkan berbagai lapisan verifikasi dan pengecekan di atasnya. Bisa lambat, dan Anda tidak bisa berkata “ini menangkap 100% bentuk kesalahan tertentu”, tetapi tetap bisa menangkap sangat banyak hal
    Ada satu data point. Analisis saya salah mengira ada satu kasus yang kecil kemungkinan menghasilkan bug nyata dan implementasinya terlihat merepotkan, jadi saya tidak menanganinya. Saya tidak yakin Opus atau Mythos, tetapi mulai melaporkan kerentanan yang berasal dari kasus itu, dan saya buru-buru memperluas analisis untuk menutup celahnya. Implementasinya memakan waktu cukup lama, dan saat memindai seluruh source tree, Claude sebenarnya sudah lebih dulu menemukan semua masalah penting yang dilaporkannya. Analisis statis memang menemukan beberapa tambahan, tetapi saya masih jujur tidak tahu apakah ada yang benar-benar bisa dipicu
    Tetap saja saya melihat nilai pada analisis statis. Beberapa kemunculan pola masalah mungkin sekarang masih hanya bisa dicapai melalui jalur yang terlalu rumit untuk dirangkai AI. Atau bisa menjadi masalah nyata saat kode lain berubah. Untuk kedua kemungkinan itu, tampaknya tetap bernilai memperbaiki semuanya sekarang, ditambah alasan yang kurang penting yaitu agar AI tidak membuang waktu mencoba mengeksploitasinya. Pada saat yang sama, jelas bahwa keseimbangan biaya-manfaatnya memang sudah berubah
    Keduanya juga bisa bekerja sama. Saya bisa melonggarkan standar saya agar alat analisis menulis laporan peringatan tambahan tentang masalah yang dicurigai, dengan ekspektasi jelas bahwa itu mungkin false positive, lalu memasukkan daftar itu ke AI untuk diverifikasi. Pada dasarnya memberi slop ke mesin slop agar ia secara nondeterministik menyaring batu permata di dalamnya
    Layak dipikirkan
  • Harness seperti ini kemungkinan memang memakai alat analisis statis, dan sepertinya akan terus begitu

• Dalam Mission Impossible terbaru, dunia hanya bisa diselamatkan jika perangkat lunak sumber asli dari AGI supermanusia yang lolos berhasil diambil dari kapal selam Rusia yang tenggelam
  Luther menulis “poison pill” yang langsung menamatkan AI itu sekali jadi jika diberi source code aslinya. Saya penasaran bagaimana kode ajaib ini ditulis, dan sekarang saya tahu. Luthor tinggal memberikan source code itu ke prompt Mythos dan meminta eksploit fatal yang tak bisa diubah

• Saya penasaran bagaimana orang melihat apakah LLM akan membuat perangkat lunak lebih aman atau kurang aman dalam 5 tahun ke depan

  • Mungkin ia akan menghapus beberapa jenis masalah, dan itu kemungkinan hal yang baik. Dan hal-hal yang masih tidak aman mungkin akan dipindahkan ke bahasa lain
    Bahkan sebelum LLM muncul, sudah ada arus porting manual ke Rust. Sekarang berkat LLM, pekerjaan itu akan lebih mudah dan cepat. Nilai jangka panjangnya akan datang dari membereskan gunungan utang teknis berupa codebase C/C++ lama. Codebase inilah yang bertanggung jawab atas sebagian besar eksploit memori, buffer overflow, dan masalah lain, dan semuanya terus ditemukan di codebase utama meskipun sudah diperhatikan selama puluhan tahun
    Temuan Mozilla atas masalah-masalah ini dibangun di atas kerja engineer yang sangat kompeten yang selama 25 tahun berusaha melakukan hal yang benar dan mencegah masalah semacam ini dengan semua alat yang tersedia. Saya sangat menghormati tim itu dan kontribusi mereka selama bertahun-tahun dalam meningkatkan alat, pengujian, dan praktik verifikasi. Masalahnya bukan pada usaha atau kemampuan mereka
    Mengambil sistem lama yang sudah teruji, terdokumentasi, dan terspesifikasi dengan baik lalu membuat implementasi pengganti drop-in kini menjadi sesuatu yang bisa ditinjau secara realistis. Beberapa tahun lalu itu akan menjadi biaya proyek dan risiko yang sangat besar, tetapi sekarang itu hal yang bisa dicoba pada Jumat sore. Skenario terburuknya gagal, skenario terbaiknya Anda mendapatkan implementasi yang jauh lebih baik
    Ini masih tahap awal dan kode buatan LLM masih punya banyak masalah kualitas. Tetapi tingkat keberhasilan dan kegagalannya kemungkinan akan membaik seiring waktu
  • Keduanya. Orang yang terampil akan memakainya untuk mencari masalah, dan orang yang kurang terampil akan memakainya untuk membuat kode slop yang tidak aman yang harus diperbaiki oleh orang terampil
  • Mirip seperti toko perlengkapan rumah, power tool, hardware yang mudah didapat, dan tutorial YouTube memungkinkan orang membuat furnitur yang luar biasa bagus dan kokoh, tetapi juga furnitur yang jelek, kasar, bahkan berbahaya
    Saat lebih banyak orang punya lebih banyak alat, lebih banyak benda dari rentang yang lebih luas akan dibuat
  • Perangkat lunak akan menjadi lebih aman, tetapi mungkin dengan cara yang mirip seperti populasi menjadi lebih sehat setelah wabah
  • Jika diterapkan dengan tepat, perangkat lunak akan menjadi lebih aman
    Hanya saja itu juga berarti untuk proyek yang tidak menerapkan alat seperti ini, black hat akan lebih mudah mendapat peluang untuk mengeksploitasinya

[GN⁺]

Opini di Lobste.rs

• Semoga mereka juga merilis prompt dan fitur-fitur lain yang dipakai untuk pekerjaan ini
  Akan bagus kalau prompt disertakan dalam laporan bug atau catatan perbaikan agar bisa direproduksi
  Karena model non-Mythos juga disebutkan, sebagian dari pekerjaan ini tampaknya bisa langsung berguna bagi orang lain juga

  • Untuk kebanyakan proyek, hambatan masuknya sebenarnya sangat rendah
    Pada dasarnya cukup bilang, “Tinjau proyek ini dari sudut pandang isu keamanan, mulai dari (file), lalu daftarkan semua jalur yang mungkin,” lalu untuk tiap item lanjutkan dengan, “Verifikasi laporan ini dan buatkan proof of concept.”
    Sekarang, dengan Opus, justru lebih sulit untuk tidak menemukan sesuatu dengan cara seperti ini
  • Memangnya menurutmu prompt-nya akan lebih dari sekadar “cari kerentanan keamanan di codebase ini”?

• Apa pun pendapat orang, ini benar-benar mengesankan
  Mereka menemukan 271 isu keamanan dengan Mythos, dan total 423 secara keseluruhan
  Di antaranya 180 berkategori keparahan tinggi, dan beberapa isu keamanan itu sudah berumur 20 tahun

  • Seberapa adil perbandingan Opus 4.6 / Mythos masih belum sepenuhnya jelas
    Tulisannya memberi kesan seolah Mythos menemukan “271 bug” pada kode yang sebelumnya dipindai dengan 4.6 dengan cara yang sama, tetapi artikelnya sendiri tidak mengatakan itu secara persis
    Saya juga penasaran apakah harness penelitian mereka berubah pada saat yang sama

• Bagian “salah satu dari beberapa isu sec-high yang kami perbaiki terkait XSLT” tampaknya dimasukkan karena kontroversi penghapusan XSLT

• Yang paling membuat saya penasaran di sini adalah berapa banyak false positive yang juga dilaporkan
  Saya penasaran apakah model itu melaporkan potensi kerentanan sekitar dua kali lebih banyak, dan yang ditampilkan di sini hanya yang sudah terkonfirmasi
  Saya juga tidak tahu apakah model itu mereproduksinya sendiri sebelum melapor
  Kalau melihat isu-isu yang dipublikasikan, tampak ada komentar yang mencoba mereproduksinya, meski itu juga bisa saja dilakukan oleh bot yang sudah ada sebelumnya
  Saya kurang tahu bagaimana Firefox biasanya menangani hal seperti ini, atau bagaimana mereka melakukannya sekarang bersama AI, jadi penjelasan yang lebih rinci akan sangat menarik