Laporan keamanan curl yang dibuat AI

• Proyek curl menjalankan bug bounty, dan seiring meningkatnya laporan keamanan yang tampaknya dibuat dengan LLM, waktu pengembang habis untuk memverifikasi laporan palsu alih-alih menangani kerentanan nyata
• Hingga kini curl telah membayar lebih dari 70 ribu dolar AS dan menerima 415 laporan, tetapi masalah keamanan nyata hanya 64 kasus, sementara 77 kasus diklasifikasikan sebagai informative
• Inti masalahnya adalah laporan-laporan ini hadir dengan bahasa Inggris yang meyakinkan, penjelasan rinci, bahkan usulan perbaikan, sehingga secara signifikan menaikkan biaya peninjauan
• Pada 2023, ada laporan yang mengklaim publikasi perubahan kode CVE-2023-38545 serta laporan buffer overflow WebSocket, tetapi masing-masing ternyata tidak ada publikasi nyata maupun buffer overflow
• AI bisa berguna sebagai alat bantu terjemahan/penulisan atau alat pendeteksi kerentanan, tetapi mengirim keluaran LLM tanpa verifikasi manusia memindahkan biaya respons keamanan open source ke proyek

---

Laporan berkualitas rendah yang dihadapi bug bounty curl

• Proyek curl menjalankan bug bounty yang membayar imbalan sungguhan kepada peretas yang melaporkan masalah keamanan
• Kemungkinan mendapatkan imbalan menarik “luck seekers” yang hanya melakukan grep pola pada source code atau menjalankan scanner keamanan dasar, lalu mengirim hasilnya tanpa analisis memadai
• Di masa lalu, laporan berkualitas rendah umumnya bisa cepat diidentifikasi dan dibuang, sehingga pemborosan waktu proyek tidak berkembang menjadi masalah besar
• Hasil bug bounty curl sejauh ini:
  • Lebih dari 70 ribu dolar AS dibayarkan sebagai imbalan
  • 415 laporan kerentanan diterima
  • 64 dikonfirmasi sebagai masalah keamanan nyata
  • 77 diklasifikasikan sebagai informative, biasanya berupa bug biasa dan sejenisnya
  • 66% dari seluruh laporan bukan isu keamanan maupun bug umum

Mengapa laporan palsu yang meyakinkan lebih berbahaya

• Semakin canggih sebuah laporan palsu, semakin banyak waktu investigasi dan energi yang diperlukan sebelum bisa dibuang
• Semua laporan keamanan harus dibaca langsung oleh manusia dan dinilai makna sebenarnya
• Pekerjaan keamanan cenderung diberi prioritas tinggi, sehingga laporan palsu pun dapat menggeser pekerjaan pengembangan lain
• Laporan yang tidak meningkatkan keamanan nyata merampas waktu yang bisa dipakai untuk memperbaiki bug yang mengganggu atau mengembangkan fitur baru
• Menangani laporan berkualitas rendah yang berulang juga memperbesar pengurasan energi pengembang

Laporan keamanan yang tampaknya dibuat AI

• AI adalah alat serbaguna sehingga bisa dipakai untuk hal baik, tetapi juga mudah dimanfaatkan dengan cara yang keliru
• Ada kemungkinan AI digunakan secara produktif untuk mendeteksi dan melaporkan masalah keamanan, tetapi proyek curl belum menemukan contoh yang baik
• Saat ini terlihat pola pengguna memasukkan kode curl ke LLM, lalu mengirim keluarannya sebagai laporan kerentanan keamanan
• Deteksi menjadi lebih sulit karena pengguna tidak sekadar menempelkan keluaran AI apa adanya, tetapi juga mencampurnya dengan kalimat sendiri
• Walaupun keseluruhan laporan tidak persis sama dengan kalimat AI, pada akhirnya laporan itu tetap bisa tidak valid

Mengapa sulit membuang laporan hanya karena ada jejak AI

• Di antara pelapor, ada yang tidak fasih berbahasa Inggris sehingga perlu beberapa putaran tanya jawab untuk memahami maksudnya
• Hambatan bahasa dan budaya memang ada, dan proses komunikasi seperti ini sendiri bisa diterima sebagai hal yang wajar
• Sebagian pelapor menggunakan AI atau alat lain sebagai bantuan terjemahan dan penulisan agar dapat berkomunikasi lebih baik dalam bahasa asing
• Pelapor yang tidak mahir berbahasa Inggris pun tetap bisa menemukan dan melaporkan masalah keamanan nyata
• Karena itu, sulit untuk langsung membuang laporan hanya karena sebagian teksnya memiliki jejak buatan AI, dan laporan palsu yang ditulis dengan baik membutuhkan waktu lebih lama untuk dikenali

Kasus A: Klaim publikasi perubahan kode CVE-2023-38545

• Pada musim gugur 2023, komunitas curl diberi tahu tentang rencana publikasi CVE-2023-38545 yang dinilai berkategori high severity
• Sehari sebelum isu tersebut dipublikasikan, sebuah laporan berjudul “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet” diterima di HackerOne
• Dari judulnya saja, jika benar, ini bisa menjadi masalah besar
• Namun laporan tersebut tampak seperti halusinasi khas AI, mencampur fakta dan detail dari isu keamanan lama untuk menciptakan isi baru yang tidak terhubung dengan kenyataan
• Perubahan untuk CVE-2023-38545 tidak dipublikasikan di internet, dan perubahan yang sudah tersedia publik memang sengaja berkaitan dengan isu lama sebelumnya
• Pelapor menyatakan bahwa ia menemukan isu ini menggunakan Bard, sehingga kesalahannya lebih mudah dipahami dan laporan lebih mudah ditutup

Kasus B: Klaim buffer overflow WebSocket

• Pada pagi 28 Desember 2023, laporan “Buffer Overflow Vulnerability in WebSocket Handling” diterima di HackerOne
• Dari judulnya terlihat serius, tetapi kode WebSocket curl masih merupakan fitur eksperimental, sehingga tidak termasuk cakupan bug bounty
• Pelapor adalah pengguna yang baru pertama kali terlihat, tetapi reputasinya di HackerOne cukup baik, dan ini juga bukan laporan keamanan pertamanya
• Laporannya tersusun rapi, memuat detail, kalimat bahasa Inggris yang sesuai, hingga usulan perbaikan
• Awalnya laporan ini tampak lebih baik daripada laporan pertama rata-rata, dan pelapor tampak memahami masalah serta menawarkan solusi
• Setelah 19 menit dan beberapa kali memeriksa kode, buffer overflow yang diklaim tidak dapat ditemukan
• Setelah pertanyaan berulang dan beberapa jawaban bernuansa halusinasi, disimpulkan bahwa ini bukan masalah nyata, dan isu tersebut ditutup sebagai not applicable pada sore hari yang sama
• Tidak dapat dipastikan apakah jawaban-jawaban itu dibuat oleh LLM, tetapi ada beberapa tanda yang tersisa

Fitur pemblokiran HackerOne dan penalti reputasi

• Awalnya dinilai bahwa HackerOne tidak memiliki fitur untuk secara eksplisit memblokir pelapor dari komunikasi lanjutan dengan proyek
• Disebutkan bahwa fitur tersebut akan digunakan jika memang ada
• Menutup isu sebagai not applicable menurunkan reputasi peneliti di HackerOne, tetapi jika hanya terjadi sekali pada satu proyek, efek penaltinya sangat kecil
• Dalam pembaruan berikutnya, ditambahkan bahwa fitur tersebut sebenarnya ada, hanya saja lokasinya tidak terlihat sebelumnya

Laporan buatan LLM akan semakin banyak

• Laporan jenis ini diperkirakan akan makin umum seiring waktu
• Proyek dapat belajar mendeteksi sinyal generated-by-AI dengan lebih baik dan membuang laporan berdasarkan sinyal tersebut
• Namun, hal ini juga bisa merugikan kasus ketika AI dipakai secara tepat, misalnya untuk membantu terjemahan atau penyusunan kalimat
• Ke depan, sebagian alat yang menggunakan AI untuk menemukan masalah keamanan mungkin benar-benar bekerja lebih baik
• Jika ditambahkan verifikasi manusia meski pada tingkat yang sangat kecil, kegunaan dan hasil alat semacam ini diperkirakan akan jauh lebih baik
• Pencarian jalan pintas demi imbalan cepat kemungkinan besar akan terus berlanjut, dan karena akses ke LLM yang kuat kini mudah, kotak masuk HackerOne diperkirakan akan menerima lebih banyak laporan berkualitas rendah

[GN⁺]

Opini Hacker News

• Kalimat seperti “Tentu! Saya akan menjelaskan lebih rinci kekhawatiran yang diajukan oleh petugas triase” adalah gaya bicara LLM yang khas, dan terdengar seperti kepala pelayan robot
  Saya hampir tidak pernah melihat orang sungguhan menulis seperti ini, dan menyebut “petugas triase” dalam orang ketiga juga terasa aneh, seolah ada pihak lain yang memicu respons itu
  Tidak masalah jika LLM punya gaya bicara unik yang bisa dikenali, tetapi yang mengkhawatirkan bukan LLM berbicara seperti manusia, melainkan manusia mulai berbicara seperti LLM

  • Daniel Stenberg[1] menyoroti poin yang bagus: curl dipakai di seluruh dunia, jadi sama sekali tidak aneh jika orang yang bahasa ibunya bukan Inggris memakai bantuan LLM untuk menulis laporan bug
    Jadi, hanya dari petunjuk permukaan bahwa kalimat bahasa Inggrisnya tampak dibuat LLM, kita tidak bisa menyimpulkan bahwa isi laporannya sendiri juga dibuat oleh LLM

    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • Saya berharap di suatu tempat ada orang yang sedang menulis sci-fi distopia tentang para penguasa robot yang terus meminta maaf sambil berkata “pada akhirnya, apakah Anda menyerah bergantung pada kebutuhan dan preferensi spesifik Anda”

  • Saat melihat ungkapan “terdengar seperti kepala pelayan robot”, tiba-tiba saya paham istilah Butlerian Jihad

  • Di India, bahasa Inggris kadang diajarkan dalam gaya Inggris untuk kelas pelayan era kolonial, yang disebut gaya “butler”
    Kalau sejauh ini Anda belum pernah melihat gaya bicara seperti ini, sepertinya Anda belum pernah berurusan dengan dukungan teknis korporat Microsoft

  • Ini jelas sinyal bahaya besar, tetapi kalau memang orang sungguhan yang menyampaikan isi sampah itu, mereka cukup menghapus satu baris tersebut
    Isinya tetap mencurigakan, tetapi petunjuk untuk menyadarinya akan jauh lebih sedikit

• Orang-orang yang mengincar “imbalan mengemis” sudah membuat pengelolaan program bug bounty cukup merepotkan
  Saat itu, orang sungguhan masih harus meluangkan waktu untuk membuat “laporan bug” yang pada dasarnya tidak berisi apa-apa, tetapi dengan LLM, laporan palsu bisa dibuat nyaris tanpa biaya sehingga benar-benar bisa menjadi tak terkendali
  Secara pribadi, saya pikir ini bisa menjadi akhir dari program bug bounty
  Atau mungkin harus dibuat lebih tertutup: menerima pendaftaran untuk ikut program, lalu memverifikasi secara murah bahwa mereka orang sungguhan, peneliti keamanan yang nyata, dan memang ingin mencari bug keamanan berdampak, kemudian hanya orang yang disetujui yang bisa mengirim bug dan menerima imbalan uang

  • Sudah ada platform yang menyediakan fitur seperti itu
    Mereka mengelola peneliti yang dikenal sebagai pool dan melacak statusnya, serta memungkinkan pengaturan seberapa terbuka sebuah program dijalankan
    Sebagian juga menyediakan petugas triase, tetapi keberhasilannya cukup bergantung pada seberapa tipikal proyeknya
  • Bisa juga ada cara dengan menerapkan biaya pengajuan
    Entah apakah itu akan membantu, tetapi bisa menjadi penghalang terhadap kiriman sampah yang dibuat massal oleh mesin
    Skenario terburuknya adalah sampah AI diajukan secara massal, lalu untuk “menyelesaikannya” diterapkan penyaringan AI yang sama buruknya, sehingga kualitas keseluruhan bagi semua orang yang ingin berpartisipasi dengan niat baik ikut menurun

• Awalnya saya kira tulisan ini duplikat dari https://news.ycombinator.com/item?id=37904047, tetapi ternyata ini adalah laporan kerentanan palsu buatan LLM lain yang diajukan terhadap curl di HackerOne

  • Syukurlah ternyata saya tidak gila
    Saat membaca, saya merasa pasti pernah melihatnya sebelumnya, tetapi kasus ini begitu mirip dengan kejadian sebelumnya sampai terasa aneh
    Apakah proyek populer seperti Curl akan terus mendapat laporan insiden yang ditulis LLM dari orang-orang yang ingin menambah satu baris di CV mereka?
  • Pelanggan HackerOne adalah perusahaan-perusahaan yang menjalankan program bug bounty
    Sepertinya mereka perlu lebih hati-hati mengelola siapa saja yang bisa mengirim spam sampah LLM yang hanya mengejar pengakuan kepada pelanggan mereka
  • Saya sama sekali tidak tahu bahwa hal seperti ini pernah terjadi sebelumnya
    Kalau begitu, kejadian ini menjadi preseden yang lebih jelas

• Hal yang paling mengkhawatirkan adalah biaya LLM beberapa sen telah membuang banyak waktu rekayasa yang mahal dan penting
  Kalau membayangkan berapa banyak upaya yang harus dikeluarkan untuk membongkar berbagai informasi palsu yang sedang dibuat sekarang, ini mirip dengan hukum Brandolini

  • Benar, LLM punya potensi merusak bagian besar internet, dan saya tidak yakin apakah ini masalah yang bisa diselesaikan
    Model saat ini punya petunjuk yang kentara, tetapi model masa depan akan berbeda dan lebih baik
    Deteksi dan pemblokiran akan menjadi perlombaan senjata, yang mungkin sulit diikuti oleh banyak orang produktif dan platform

• Menarik bahwa kita telah mengubah tulisan, sarana berbandwidth paling rendah untuk membuktikan tindakan dan upaya, menjadi sesuatu yang jauh lebih padat kerja untuk menilai apakah tindakan atau upaya nyata memang pernah ada
  Dampak lanjutannya mungkin akan sangat besar
  Dalam kasus ini, baik pelapor maupun pengelola membuang waktu yang bisa dipakai untuk hal yang lebih berguna, dan seluruh proses bug bounty serta CVE berbasis crowdsourcing rusak karena rasio sinyal terhadap derau yang menurun
  Akibatnya, kemungkinan besar hambatan pengajuan akan dinaikkan untuk menangani spam, yang bisa berujung pada lebih sedikit bug yang ditemukan dan diperbaiki, lebih banyak kerentanan keamanan, serta semua masalah turunannya
  Dinamika yang sama juga berlaku di bidang lain, sehingga ulasan produk, dokumen pengajuan pengadilan, resep, panduan penggunaan, saran medis, dan sebagainya makin tidak bisa dipercaya
  Salah satu janji internet adalah perluasan konten secara cepat lewat demokratisasi penerbitan, tetapi rasanya kita sedang melihat bahkan manfaat yang tersisa pun digerogoti dari dalam

• Mempermasalahkan pemeriksaan batas panjang di sini terasa sangat aneh
  Tidak ada data yang diberikan pengguna yang dipakai, dan semua ukuran bersifat statis pada waktu kompilasi
  curl memasukkan string acak 16 byte yang dienkode base64, yaitu 25 byte ASCII ditambah karakter terminasi null \0, ke dalam buffer statis 40 byte

  https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

Dan kalau murni karena penasaran, bisakah seseorang yang lebih paham C daripada saya menjelaskan kenapa variabel lokal keyval dipakai di sini?
Kenapa tidak cukup set heads[3].val = randstr, lalu setelah pemrosesan data header selesai, panggil free()?
Dan kenapa keyval 40 byte, bukan 26 atau 32 byte?

• Mungkin maksudnya untuk mengurangi tempat yang harus memanggil free, sekaligus mengurangi kemungkinan lupa memanggilnya
  Di baris 580 mungkin tampak hal seperti itu bisa terjadi, tetapi sebenarnya kasus itu mungkin sama sekali tidak pernah terjadi

• Kalau begitu, hapus saja randstr dan keyval, lalu karena toh dialokasikan, langsung encode ke &heads[3].val
  Tetap harus mengoper randlen yang tidak berguna, kalau tidak akan crash
  Itulah keindahan khas parameter keluaran di C
  Tarian “menyalin dari heap ke variabel stack” ini juga tidak mengurangi pekerjaan pembersihan
  Karena setelah encoding, hanya ada satu jalur return tanpa syarat
  Namun jika awalnya variabel yang diperlukan sudah “disiapkan” di atas lalu belakangan menyadari bahwa Curl_base64_encode selalu mengalokasikan, saya bisa memahami bagaimana kode yang sekarang muncul

• Menggunakan stack nyaris gratis karena ruangnya sudah dicadangkan saat penyiapan fungsi dan otomatis dibersihkan ketika fungsi return
  Menggunakan heap butuh lebih banyak pekerjaan, bisa gagal, dan perlu pembersihan manual

• Salah satu pelajaran penting yang saya dapat di SMA adalah cara membedakan kebohongan yang diungkapkan dengan elegan dari kebenaran yang diungkapkan dengan kasar
  Tapi itu bisa sulit
  Orang cenderung memakai tata bahasa dan gaya yang benar sebagai filter pertama untuk wacana intelektual, dan LLM sangat, sangat piawai membuat bentuk bahasa tampak meyakinkan

  • Saya penasaran seberapa mengena pelajaran ini bagi saya dan teman-teman sekelas saat itu
    Ini masalah yang sangat rumit, dan menurut saya kebanyakan orang dewasa pun tidak siap menanganinya
    Orang rata-rata sebenarnya cukup mampu membedakan keduanya, tetapi masalahnya adalah mereka harus terbiasa membaca tulisan secara sistematis dan mau mengerahkan usaha
    Saat menggulir ponsel larut malam, melakukan itu sangat sulit

• Kalau bukan karena menyebalkan dan membuang waktu, situasi ketika dineshsec / dinesh_b mencoba mengajari Daniel cara memakai strncpy sebenarnya akan lucu
  Pertama ia menandai Daniel dengan handle sembarang, lalu setelah berkata “kode bermasalahnya adalah sebagai berikut:”, ia mengarang kode yang tidak ada

  • Ini masalah klasik penyalahgunaan LLM
    Pengguna ingin menganalisis sesuatu, tetapi karena terlalu panjang, mereka memotongnya menjadi beberapa permintaan
    Lalu saat sampai ke bagian inti, potongan kode asli sudah hilang dari konteks, dan model dengan percaya diri memuntahkan sesuatu yang sebenarnya tidak ada tetapi tampak masuk akal

• Yang seharusnya dipakai bukan strcpy atau strncpy, melainkan memcpy saja
  Khususnya strncpy jelas pilihan terburuk dari ketiganya
  Kode sudah tahu ukuran buffer sumber dan sudah memeriksa apakah muat di buffer tujuan, jadi tidak ada alasan memanggil strcpy hanya untuk mengukur panjang string secara tidak perlu
  Sejujurnya, rekomendasi LLM ini sampai pada tingkat yang ingin saya larang keras
  Kalau tidak tahu ukurannya, tidak peduli pada pemotongan diam-diam, dan tidak peduli performa, pakai saja snprintf
strncpy mengisi sisa buffer dengan nol secara tidak perlu
  Kalau yang ditangani bukan semacam UI, biasanya pemotongan harus diperhatikan, dan dalam kasus seperti itu strncpy tidak akan menyelamatkan Anda

• Sepertinya terkait dengan ini: https://news.ycombinator.com/item?id=38840907