Mengeksploitasi Bug Petir Adalah Pilihan Etis

Ini adalah editorial opini oleh Shinobi, seorang pendidik otodidak di bidang Bitcoin dan pembawa acara podcast Bitcoin yang berorientasi pada teknologi.

Untuk kedua kalinya dalam waktu sekitar sebulan, btcd/LND telah mengeksploitasi bug yang menyebabkan mereka menyimpang dari konsensus Bitcoin Core. Sekali lagi, Burak adalah pengembang yang memicu kerentanan ini – kali ini jelas-jelas disengaja – dan sekali lagi, ini adalah masalah kode untuk menguraikan transaksi Bitcoin di atas lapisan konsensus. Seperti yang saya bahas di saya sepotong bug sebelumnya yang dipicu Burak, sebelum Taproot ada batasan seberapa besar skrip dan data saksi dalam suatu transaksi. Dengan aktivasi Taproot, batasan tersebut dihilangkan dan hanya menyisakan batasan pada batas ukuran blok itu sendiri untuk membatasi bagian-bagian dari transaksi individual ini. Masalah dengan bug terakhir adalah meskipun kode konsensus di btcd telah ditingkatkan dengan benar untuk mencerminkan perubahan ini, kode yang menangani transmisi peer-to-peer — termasuk penguraian data sebelum mengirim atau saat menerima — tidak ditingkatkan dengan benar. Jadi blok pemrosesan kode dan transaksi sebelum benar-benar diteruskan untuk divalidasi karena konsensus gagal dalam data, tidak pernah meneruskannya ke logika validasi konsensus dan blok tersebut gagal untuk divalidasi.

Hal serupa terjadi kali ini. Batasan lain di bagian basis kode peer-to-peer adalah menerapkan pembatasan yang salah pada data saksi, membatasinya hingga maksimum 1/8 ukuran blok dibandingkan dengan ukuran blok penuh. Burak membuat a . dengan data saksi hanya satu unit bobot yang melampaui batas ketat dan sekali lagi menghentikan node btcd dan LND pada ketinggian blok tersebut. Transaksi ini adalah transaksi non-standar, yang berarti meskipun transaksi ini benar-benar valid berdasarkan aturan konsensus, transaksi ini tidak valid menurut kebijakan mempool default dan oleh karena itu node tidak akan meneruskannya ke seluruh jaringan. Sangat mungkin untuk menambangnya ke dalam satu blok, tetapi satu-satunya cara untuk melakukannya adalah dengan memberikannya langsung ke penambang, seperti yang dilakukan Burak dengan bantuan F2Pool.

Hal ini benar-benar menegaskan bahwa setiap bagian kode yang tujuannya adalah untuk mengurai dan memvalidasi data Bitcoin harus diaudit secara mendalam untuk memastikannya sejalan dengan apa yang akan dilakukan Bitcoin Core. Tidak masalah apakah kode tersebut adalah mesin konsensus untuk implementasi node atau hanya sepotong kode yang meneruskan transaksi untuk node Lightning. Bug kedua ini adalah benar-benar tepat di atas yang dari bulan lalu dalam basis kode. Itu bahkan tidak ditemukan oleh siapa pun di Lightning Labs. AJ Towns melaporkannya pada 11 Oktober, dua hari setelah bug asli dipicu oleh 998 dari 999 transaksi multisig Burak. Itu diposting secara publik di Github selama 10 jam sebelum dihapus. Perbaikan kemudian dilakukan, namun tidak dirilis, dengan maksud untuk secara diam-diam menambal masalah tersebut pada rilis LND berikutnya.

Sekarang, ini adalah prosedur standar untuk kerentanan yang serius, terutama dengan proyek seperti Bitcoin Core di mana kerentanan tersebut sebenarnya dapat menyebabkan kerusakan serius pada jaringan/protokol lapisan dasar. Namun dalam kasus khusus ini, hal ini menghadirkan risiko serius terhadap dana pengguna LND, dan mengingat fakta bahwa bug tersebut berada tepat di samping bug sebelumnya yang memiliki risiko yang sama, kemungkinan bug tersebut akan ditemukan dan dieksploitasi sangat tinggi. seperti yang ditunjukkan oleh Burak. Hal ini menimbulkan pertanyaan apakah pendekatan patch yang tenang adalah cara yang tepat untuk mengatasi kerentanan seperti ini yang dapat membuat pengguna rentan terhadap pencurian dana (karena node mereka tidak dapat mendeteksi status saluran lama dan memberikan sanksi yang tepat kepada mereka).

Saat saya membahas bug terakhir, jika aktor jahat telah menemukan bug tersebut sebelum pengembang yang bermaksud baik, mereka dapat secara taktis membuka saluran baru ke node yang rentan, mengarahkan seluruh konten saluran tersebut kembali ke saluran mereka sendiri, dan kemudian mengeksploitasi bug tersebut. Dari sana, mereka akan memiliki dana tersebut di bawah kendali mereka dan juga dapat menutup saluran dengan keadaan awal, sehingga menggandakan uang mereka. Apa yang Burak lakukan dengan aktif mengeksploitasi masalah ini dengan cara yang ironis sebenarnya melindungi pengguna LND dari serangan semacam itu.

Setelah dieksploitasi, pengguna akan rentan terhadap serangan serupa dari rekan-rekan mereka yang sudah memiliki saluran terbuka, namun mereka tidak lagi dapat ditargetkan secara khusus dengan saluran baru. Node mereka terhenti dan tidak akan pernah mengenali atau memproses pembayaran melalui saluran yang coba dibuka seseorang setelah blok yang menghentikan node mereka. Jadi, meskipun hal ini tidak sepenuhnya menghilangkan risiko eksploitasi pengguna, hal ini membatasi risiko tersebut hanya pada orang-orang yang sudah memiliki saluran dengan mereka. Tindakan Burak meringankannya. Secara pribadi menurut saya tindakan semacam ini sebagai respons terhadap bug tersebut masuk akal; itu membatasi kerusakan, membuat pengguna sadar akan risikonya dan menyebabkannya segera ditambal.

LND juga bukan satu-satunya yang terkena dampaknya. Cairan proses pegging juga rusak, memerlukan pembaruan pada fungsionaris federasi untuk memperbaikinya. Rust Bitcoin versi lama juga terpengaruh, yang menyebabkan penghentian tersebut memengaruhi beberapa penjelajah blok dan instance electrs (implementasi server backend untuk Electrum Wallet). Sekarang, dengan pengecualian pasak Liquid yang pada akhirnya memaparkan dana ke kunci pemulihan darurat yang dipegang oleh Blockstream setelah batas waktu berakhir - dan, secara realistis dalam plot film bergaya pencurian di mana Blockstream mencuri dana ini, semua orang tahu persis siapa yang harus dikejar - yang lain ini masalah tidak pernah membahayakan dana siapa pun kapan pun. Selain itu, Rust Bitcoin sebenarnya telah menambal bug khusus ini di versi yang lebih baru, yang tampaknya tidak mengarah pada komunikasi apa pun dengan pengelola basis kode lain untuk menyoroti potensi masalah tersebut. Hanya eksploitasi aktif bug secara langsung di jaringan yang mengungkap secara luas bahwa masalah tersebut ada di berbagai basis kode.

Hal ini memunculkan beberapa masalah besar terkait kerentanan seperti ini pada perangkat lunak Layer 2 pada Bitcoin. Pertama, keseriusan basis kode ini dalam mengaudit bug keamanan dan bagaimana hal tersebut diprioritaskan versus integrasi fitur-fitur baru. Saya pikir sangat jelas bahwa keamanan tidak selalu diprioritaskan mengingat bug kedua ini bahkan tidak ditemukan oleh pengelola basis kode di mana bug tersebut ada, meskipun secara harfiah bug tersebut berada tepat di sebelah bug awal yang ditemukan bulan lalu. Setelah satu bug besar yang membahayakan dana pengguna, apakah tidak ada audit internal terhadap basis kode tersebut yang dilakukan? Butuh seseorang dari luar proyek untuk menemukannya? Hal ini tidak menunjukkan prioritas untuk melindungi dana pengguna dibandingkan membangun fitur baru untuk menarik lebih banyak pengguna. Kedua, fakta bahwa masalah ini telah ditambal di Rust Bitcoin menunjukkan kurangnya komunikasi antar pengelola basis kode yang berbeda sehubungan dengan bug seperti ini. Hal ini cukup dapat dimengerti, karena basis kode yang benar-benar berbeda tidak membuat seseorang yang menemukan bug di salah satunya langsung berpikir, “Saya harus menghubungi tim lain yang menulis perangkat lunak serupa dalam bahasa pemrograman yang sangat berbeda untuk memperingatkan mereka tentang potensi bug semacam itu.” Anda tidak menemukan bug di Windows dan kemudian langsung berpikir untuk melaporkan bug tersebut ke pengelola kernel Linux. Namun, Bitcoin sebagai protokol untuk konsensus terdistribusi di jaringan global adalah hal yang sangat berbeda; mungkin pengembang Bitcoin harus mulai berpikir seperti itu ketika menyangkut kerentanan dalam perangkat lunak Bitcoin. Terutama dalam hal penguraian dan interpretasi data yang terkait dengan konsensus.

Terakhir, mungkin ketika menyangkut protokol seperti Lightning, yang bergantung pada pengamatan blockchain setiap saat agar dapat bereaksi terhadap status saluran lama demi menjaga keamanan, penguraian independen dan verifikasi data harus dijaga seminimal mungkin — jika tidak dihapus seluruhnya dan didelegasikan ke Bitcoin Core atau data yang diperoleh langsung darinya. Core Lightning dirancang dengan cara ini, terhubung ke instance Bitcoin Core dan bergantung sepenuhnya pada itu untuk validasi blok dan transaksi. Jika LND bekerja dengan cara yang sama, bug di btcd ini tidak akan memengaruhi pengguna LND sehingga membahayakan dana mereka.

Apa pun cara penanganannya — baik dengan mengalihdayakan validasi sepenuhnya atau sekadar meminimalkan validasi internal dan melakukan pendekatan dengan lebih hati-hati — kejadian ini menunjukkan bahwa ada sesuatu yang perlu diubah dalam mendekati masalah tentang bagaimana perangkat lunak Lapisan 2 menangani interaksi dengan data terkait konsensus. Sekali lagi, semua orang sangat beruntung karena hal ini tidak dieksploitasi oleh aktor jahat, melainkan oleh pengembang yang membuktikan suatu hal. Meskipun demikian, Bitcoin tidak dapat mengandalkan keberuntungan atau harapan bahwa pelaku kejahatan tidak ada.

Pengembang dan pengguna harus fokus pada peningkatan proses untuk mencegah insiden seperti ini terjadi lagi, dan tidak saling menyalahkan seperti kentang panas.

Ini adalah posting tamu oleh Shinobi. Pendapat yang diungkapkan sepenuhnya milik mereka sendiri dan tidak mencerminkan pendapat BTC Inc atau Majalah Bitcoin.