Isu backdoor xz sebagai miniatur interaksi dalam proyek open source

• Sudah ada banyak analisis tentang kerentanan xz/liblzma, tetapi kebanyakan cenderung melewatkan tahap pertama serangan
  • maintainer asli mengalami kelelahan, dan hanya penyerang yang menawarkan bantuan (sehingga penyerang mewarisi kepercayaan yang telah dibangun oleh maintainer asli).
• Arsip thread email menangkap situasi pada saat tahap 0 ini terjadi

Kelelahan maintainer dan kemunculan penyerang

• Sebuah permintaan yang tampak wajar diajukan kepada maintainer

  • "Apakah XZ for Java masih dipelihara? Saya mengajukan pertanyaan seminggu yang lalu tetapi belum ada jawaban"

• Pertanyaan ini membuat maintainer merasa harus mengakui "kegagalan"
  • padahal sebenarnya maintainer tidak berutang apa pun dan tidak gagal, tetapi terasa seperti itu
  • karena mengecewakan "komunitas" adalah hal yang mengerikan
• Maintainer mengakui bahwa dirinya "tertinggal" dan memberi sinyal seolah meminta bantuan
• Namun, dalam thread itu tidak ada bantuan yang datang, dan sebaliknya penyerang xz/liblzma memperkenalkan dirinya sebagai orang yang telah membantu

  • "Jia Tan (penyerang kali ini) telah membantu saya... dan mungkin akan mengambil peran yang lebih besar ke depannya... sumber daya saya terlalu terbatas sehingga jelas sesuatu harus berubah dalam jangka panjang."

• Maintainer menyebutkan bahwa sumber dayanya terbatas sehingga perlu ada perubahan dalam jangka panjang

Kemunculan konsumen yang tidak kooperatif

• Seorang konsumen yang tidak kooperatif melontarkan komentar kritis kepada maintainer

  • "Sepertinya tidak akan ada kemajuan sampai ada maintainer baru. ... pengelola saat ini telah kehilangan minat atau tidak lagi peduli dengan pemeliharaan. Menyedihkan melihat repositori seperti ini."

• Maintainer membela diri dengan mengatakan bahwa ia tidak kehilangan minat, tetapi kemampuannya untuk mengelola terbatas karena masalah kesehatan mental dan lain-lain
• Maintainer juga mengingatkan bahwa ini adalah proyek hobi tanpa bayaran

Peningkatan tuntutan

• Satu minggu kemudian, konsumen yang tidak kooperatif itu muncul lagi dan menyalahkan maintainer.

  • "Anda mengabaikan banyak patch yang perlahan membusuk di mailing list ini."

  • "Saya turut prihatin soal masalah kesehatan mental, tetapi penting untuk mengenali batas diri sendiri. Saya tahu proyek ini adalah proyek hobi bagi semua kontributor, tetapi komunitas menginginkan lebih."

• Orang yang meminta itu juga memberi usulan, tetapi tidak ada tawaran untuk benar-benar membantu

  • "Bagaimana kalau hak pemeliharaan untuk XZ for C diserahkan agar Anda bisa lebih fokus pada XZ for Java? Atau XZ for Java diserahkan kepada orang lain agar Anda bisa fokus pada XZ for C? Jika mencoba memelihara keduanya, bisa jadi keduanya tidak terpelihara dengan baik."

• Maintainer menjelaskan bahwa mencari co-maintainer baru atau menyerahkan proyek sepenuhnya bukanlah hal yang mudah

Realitas proyek open source

• Pengembang perangkat lunak bukan roda gigi yang bisa dipasang dan dicabut sesuka hati
• Thread email itu berakhir dengan konsumen yang mengeluh terus menambah tuntutan tanpa memberi bantuan apa pun, dan hanya penyerang yang tersisa

  • "Jia Tan mungkin akan mengambil peran yang lebih besar dalam proyek ke depan. Dia banyak membantu di luar mailing list dan pada praktiknya sudah menjadi co-maintainer. :-)"

• Thread email ini menunjukkan miniatur interaksi dalam proyek open source
• Konsumen mengajukan tuntutan kepada maintainer, dan maintainer merespons dengan berbagai cara di bawah stres dan kelelahan
• Cara seperti ini perlu diubah

[GN⁺]

Komentar Hacker News

• Ada pendapat bahwa pengembang tampaknya membuang banyak energi mental saat berusaha bersikap ramah kepada pengguna dan mencoba melihat niat baik dari para penulis komentar. Pendapat seperti ini biasanya muncul pada side project yang dikerjakan untuk bersenang-senang (emulator, remake game, dan sebagainya). Proyek-proyek seperti ini menghindari penyebutan donasi untuk menghindari masalah donasi atau hak cipta. Ada banyak minat terhadap proyek tersebut, tetapi minat yang benar-benar terampil dan bisa berkontribusi sangat terbatas. Percakapan dari pengguna diizinkan dan didorong, tetapi terkadang bisa dipersepsikan sebagai 'saran' atau 'tuntutan' yang menurunkan motivasi pengembang. Menjaga komunitas itu penting, tetapi ada juga kekhawatiran soal tidak mengecualikan orang-orang yang tidak berkontribusi secara langsung.

• Tahap pertama dari masalah ini adalah serangan rekayasa sosial yang menekan pengembang proyek open source agar menyerahkan lebih banyak kendali repositori kepada penyerang.

• Sebagai maintainer library open source yang berorientasi pada keamanan, setiap kali membaca PR, muncul beban kecurigaan: "apakah orang ini benar-benar ingin membantu, atau ingin memanfaatkan?" Saya merasa satu-satunya solusi adalah memperlambat laju pengembangan, tetapi perasaan yang muncul karenanya sama seperti yang dijelaskan dalam artikel. Kalau ada cara sederhana untuk meminta bantuan dari komunitas ahli tepercaya, saya akan selalu menyambutnya.

• Seperti kripto, AI, dan insiden ini, masalah terbesar pada akhirnya bermuara pada persoalan kepercayaan. Kripto mencoba menyelesaikan masalah kepercayaan dengan kode, LLM berusaha mendapatkan kepercayaan dengan menipu lewat kemewahan tampilannya, dan penyerang cukup berhasil dalam mencuci kepercayaan. Para teknolog yang paling penting justru tidak benar-benar memikirkan kepercayaan dengan baik. Dalam kasus ini, ada pemahaman terhadap pengembang open source yang lelah dan tidak dibayar.

• Ada pertanyaan apakah server SSH dengan port knocking yang dikonfigurasi akan aman dari backdoor ini. Karena RCE hanya bisa dijalankan setelah terhubung ke server SSH, tampaknya tidak akan menjadi masalah jika port disembunyikan di balik urutan knocking TCP/UDP yang masuk akal. Port knocking bukan pengganti konfigurasi SSH yang tepat, tetapi berguna sebagai lapisan pertahanan tambahan untuk mencegah atau memberi waktu respons ketika kerentanan SSH muncul.

• Ada tautan tentang masalah yang terkait dengan patch khusus Linux di OpenSSH. Tanpa patch ini, masalah tersebut tidak akan terjadi. Ini bukan masalah OpenSSH, melainkan masalah Linux.

• Ada pendapat bahwa orang-orang masih saja meremehkan dependensi keras dan kompleksitas bahkan setelah insiden left-pad. OpenSSH adalah tembok kode yang sangat besar. Sistem yang kompleks pada dasarnya sulit dipercaya, apa pun bahasa yang digunakan untuk menulisnya.

• Jika peretas Tiongkok ingin melakukan tindakan jahat, mengapa mereka memakai nama/handle Tiongkok? Akan lebih baik memakai nama Inggris/Eropa untuk mendapatkan lebih banyak kepercayaan dari para maintainer open source. Sebaliknya, jika peretas non-Tiongkok ingin melakukan tindakan jahat, memakai nama Tiongkok justru lebih masuk akal (Tiongkok itu jahat, dan seterusnya).

• Akun Jigar Kumar tampaknya merupakan bagian dari serangan rekayasa sosial dan seharusnya dipandang sangat mencurigakan.

• Pengembang perangkat lunak bukan komponen yang bisa diganti begitu saja, dan ada pemikiran tentang membatasi hak untuk berkomentar atau berpartisipasi di komunitas. Misalnya, jika GitHub memperkenalkan sebuah 'gerbang', gerbang pertama bisa berupa penambahan tes ke test suite yang menghasilkan nomor versi dan hash dari output tes. Jika nomor ini ditambahkan ke profil, GitHub bisa mempercayai bahwa pengguna setidaknya telah mengunduh dan menjalankan make test. Ini menunjukkan tingkat komitmen tertentu.