Laporan ini menganalisis secara rinci rincian teknis, akar penyebab, dan kemungkinan metode serangan dari kerentanan inti DoS yang ada di mesin virtual TON, sekaligus menunjukkan solusi efisien yang diusulkan oleh tim TonBit.

Baru-baru ini, sistem mesin virtual jaringan TON telah menerima peningkatan keamanan besar-besaran. TonBit, tim keamanan di bawah BitsLab, berhasil menemukan dan membantu memperbaiki kerentanan inti yang dapat menyebabkan habisnya sumber daya mesin virtual TON. Kerentanan ini mengeksploitasi mekanisme rekursif mesin virtual saat memproses Continuation nesting, dan dapat disalahgunakan oleh kontrak jahat, menyebabkan sistem crash dan ketidakstabilan jaringan.

Jika kerentanan ini dieksploitasi secara jahat, tidak perlu menghabiskan satu TON pun, yang dapat membuat semua node verifikasi down, secara langsung mengancam ketersediaan jaringan. Dalam peristiwa ini, TonBit dengan kemampuan teknisnya yang luar biasa dengan cepat mengidentifikasi kerentanan dan melalui penyesuaian mekanisme aliran kontrol internal mesin virtual, mengajukan solusi inovatif untuk menggantikan rekurif dengan iterasi, berhasil menciptakan lingkungan ekosistem yang lebih aman bagi pengguna TON. Tim resmi TON secara khusus mengucapkan terima kasih kepada TonBit atas kontribusi luar biasa mereka terhadap keamanan ekosistem dalam pengumuman pembaruan terbaru mereka.

Dalam laporan keamanan terperinci berikut ini, kami akan menganalisis penyebab, detail teknis, dan solusi dari kerentanan ini secara mendalam. Laporan ini menjelaskan secara rinci bagaimana kerentanan memanfaatkan kedalaman bersarang dari Continuation untuk membangun rantai rekurif yang memicu serangan kehabisan sumber daya, serta bagaimana kontrak jahat dapat menghabiskan ruang tumpukan host dengan memperluas tumpukan panggilan. Selain itu, kami juga akan memperkenalkan bagaimana tim TonBit menghilangkan cacat desain dari rantai rekurif ini dan mengadopsi mekanisme iterasi kolaboratif untuk membantu menyelesaikan masalah ini secara menyeluruh. Perbaikan ini tidak hanya secara signifikan meningkatkan stabilitas jaringan TON, tetapi juga memberikan referensi penting untuk keamanan dasar di industri blockchain.

Studi Kasus: Kerentanan DoS dalam TON VM dan langkah-langkah mitigasi terkait

Pendahuluan

Laporan ini menggambarkan kerentanan DoS (penolakan layanan) dalam mesin virtual TON dan langkah-langkah mitigasi untuk mengatasi masalah tersebut. Kerentanan ini disebabkan oleh cara mesin virtual menangani proses bersarang dari Continuation selama eksekusi kontrak. Kerentanan ini memungkinkan kontrak jahat untuk membuat Continuation dan bersarang dalam cara tertentu, sehingga memicu rekurif mendalam selama proses evaluasi, menghabiskan ruang tumpukan host dan menghentikan mesin virtual. Untuk mengatasi masalah ini, mesin virtual telah mengubah cara penanganan Continuation dan aliran kontrol. Sekarang, mesin virtual tidak lagi melakukan panggilan ekor secara berurutan melalui rantai Continuation, tetapi dengan aktif mengiterasi rantai. Metode ini memastikan hanya menggunakan ruang tumpukan host yang konstan, mencegah overflow tumpukan.

Ringkasan

Menurut dokumentasi resmi, TON VM adalah mesin virtual berbasis tumpukan yang menggunakan Gaya Penyampaian Continuation (CPS) sebagai mekanisme aliran kontrolnya, digunakan untuk alur internal dan kontrak pintar. Register aliran kontrol dapat diakses oleh kontrak, sehingga memberikan fleksibilitas.

Teori Continuation dalam TVM secara teoritis dapat dibagi menjadi tiga kategori:

  • OrdCont (yaitu vmc_std), berisi potongan TON ASM yang perlu dieksekusi, adalah objek tingkat satu dalam TVM. Kontrak dapat secara eksplisit membuat dan meneruskannya pada waktu berjalan untuk mencapai aliran kontrol yang sewenang-wenang.

  • Continuation yang tidak biasa (Extraordinary continuations), biasanya mencakup OrdCont sebagai komponen, dibuat melalui primitif iterasi eksplisit dan operasi implisit khusus, digunakan untuk menangani mekanisme aliran kontrol yang sesuai.

  • ArgContExt tambahan, membungkus Continuation lainnya untuk menyimpan data kontrol.

Dalam proses eksekusi kontrak, mesin virtual memasuki loop utama, setiap kali mendekode satu kata dari potongan kontrak dan mendistribusikan operasi yang sesuai ke handler yang sesuai. Handler biasa segera kembali setelah mengeksekusi operasi yang sesuai.

Secara relatif, instruksi iterasi akan menggunakan Continuation yang disediakan sebagai komponen untuk membuat sebuah Continuation yang tidak biasa, dan melompat ke Continuation yang tidak biasa tersebut dalam konteks yang sesuai. Continuation yang tidak biasa itu sendiri mengimplementasikan logika saat melompat, dan melompat ke komponen tertentu berdasarkan kondisi. Misalnya, saat menggunakan instruksi WHILE, kita dapat mendemonstrasikan proses ini dalam Gambar 1 (mengabaikan kemungkinan keluar).

Gambar 1: Logika Continuation yang tidak biasa

Penyebab mendasar

Dalam versi mesin virtual yang memiliki kerentanan, lompatan ini akan menyebabkan panggilan ekor dinamis yang berurutan, yang mengharuskan tumpukan host untuk mempertahankan satu bingkai tumpukan untuk setiap lompatan (seperti yang ditunjukkan pada gambar 2).

Sebagai contoh WhileCont, bagian lainnya dihilangkan untuk kesederhanaan.

Gambar 2: Rekursi lompatan tiga untuk bersarang lebih dalam

Dalam kondisi ideal, ini tidak akan menjadi masalah karena komponen biasanya direpresentasikan sebagai OrdCont, yang lompatan hanya akan menyimpan konteks saat ini, lalu memberi tahu mesin virtual untuk mengeksekusi potongan yang dimilikinya, melaksanakan sebelum sisa potongan kontrak dan tidak akan memperkenalkan lebih banyak rekurif. Namun, Continuation yang tidak biasa secara teoritis dirancang untuk memungkinkan komponen mereka mengakses register cc (c0) dalam TVM (yaitu cabang set_c0 yang disebutkan di atas). Oleh karena itu, kontrak dapat menyalahgunakan fungsi ini untuk melakukan rekurif yang dalam (akan dijelaskan kemudian). Dibandingkan dengan mengubah implementasi fungsi reguler ini, lebih jelas dan lebih mudah untuk menghilangkan rekurif selama proses lompatan dari Continuation yang tidak biasa.

Dengan menggunakan Continuation yang tidak biasa yang telah diperoleh secara berulang untuk membangun Continuation yang tidak biasa tingkat atas, kita dapat membuat Continuation yang bersarang dalam kedalaman melalui iterasi. Continuation yang bersarang dalam kedalaman ini, saat dievaluasi, dapat menghabiskan ruang tumpukan yang tersedia di host, menyebabkan sistem operasi mengeluarkan sinyal SIGSEGV dan menghentikan proses mesin virtual.

Gambar 3 memberikan konsep verifikasi proses bersarang (PoC).

Gambar 3: Proses bersarang

Kami melihat bahwa dalam setiap iterasi, entitas memperluas satu WhileCont{chkcond=true}. Dengan mengeksekusi cc yang dihasilkan dan disimpan dalam iterasi sebelumnya, kita akan mendapatkan tumpukan panggilan yang mirip dengan ini:

Dapat dilihat bahwa ruang tumpukan memiliki hubungan ketergantungan linier dengan tingkat bersarang (yaitu jumlah iterasi), yang menunjukkan kemungkinan dapat menyebabkan kehabisan ruang tumpukan.

Tentang pemanfaatan dalam lingkungan nyata

Dalam blockchain nyata, batas biaya bahan bakar membuat konstruksi kontrak jahat cukup sulit. Karena kompleksitas linier dari proses bersarang (desain TVM secara efektif mencegah konstruksi yang lebih murah melalui referensi diri), mengembangkan kontrak jahat yang praktis bukanlah hal yang mudah. Secara spesifik, satu tingkat bersarang akan menghasilkan urutan panggilan, yang menghabiskan tiga bingkai tumpukan host (320 byte) dalam berkas biner debug, sementara dalam berkas biner rilis menghabiskan dua (256 byte, dua panggilan terakhir disisipkan menjadi satu). Untuk node verifikasi yang berjalan di sistem operasi POSIX modern, ukuran tumpukan default adalah 8MiB, yang cukup untuk mendukung lebih dari 30.000 tingkat bersarang dalam berkas biner rilis. Meskipun masih mungkin untuk membangun kontrak yang dapat menghabiskan ruang tumpukan, tetapi ini jauh lebih sulit dibandingkan dengan contoh di bagian sebelumnya.

Langkah mitigasi

Patch ini mengubah perilaku lompatan dalam situasi bersarang Continuation. Kita dapat melihat tanda tangan lompatan dari Continuation telah berubah.

Sebagai contoh UntilCont, bagian lainnya dihilangkan untuk kesederhanaan.

Tidak lagi memanggil VmState::jump untuk melompat ke Continuation berikutnya, yang berarti mengeksekusi tiga lompatan berurutan secara rekurif pada setiap Continuation dan menunggu nilai pengembalian untuk menyebar ke belakang. Sekarang, lompatan Continuation hanya menguraikan tingkat berikutnya dari Continuation, dan kemudian mengembalikan kontrol ke mesin virtual.

Mesin virtual secara kolaboratif mengiterasi setiap tingkat Continuation sampai menemui NullRef, yang menunjukkan bahwa penguraian rantai telah selesai (seperti diimplementasikan dalam OrdCont atau ExuQuitCont). Dalam proses iterasi ini, hanya satu lompatan Continuation yang selalu dialokasikan di tumpukan host, sehingga memastikan penggunaan tumpukan tetap konstan.

Kesimpulan

Untuk layanan yang memerlukan ketersediaan tinggi, penggunaan rekurif dapat menjadi vektor serangan yang berpotensi. Ketika melibatkan logika yang ditentukan pengguna, memaksa penghentian rekurif dapat menjadi tantangan. Kerentanan DoS ini menunjukkan kasus ekstrem di mana fungsi normal disalahgunakan secara tidak sengaja dalam kondisi sumber daya terbatas (atau kondisi lain). Jika rekurif bergantung pada input pengguna, masalah serupa dapat terjadi, yang sangat umum dalam primitif aliran kontrol mesin virtual.

Laporan ini menganalisis secara rinci detail teknis, penyebab mendasar, dan kemungkinan cara serangan dari kerentanan DoS inti yang ada dalam mesin virtual TON, sekaligus menunjukkan solusi efisien yang diajukan oleh tim TonBit. Dengan menyesuaikan mekanisme lompatan rekurif mesin virtual menjadi pengolahan iteratif, TonBit berhasil mengajukan solusi perbaikan untuk kerentanan ini, membantu memperbaiki kerentanan inti yang dapat menyebabkan jaringan lumpuh, dan memberikan jaminan keamanan yang lebih kuat bagi ekosistem TON. Peristiwa ini tidak hanya mencerminkan akumulasi mendalam TonBit di bidang keamanan teknologi dasar blockchain, tetapi juga menunjukkan perannya yang penting sebagai Penyedia Jaminan Keamanan (SAP) resmi TON.

Sebagai mitra keamanan yang tak terpisahkan dari ekosistem TON, TonBit selalu berada di garis depan industri dalam melindungi stabilitas jaringan blockchain dan keamanan aset pengguna. Dari penemuan kerentanan hingga desain solusi, TonBit dengan kemampuan teknisnya yang kuat dan pemahaman mendalam tentang perkembangan blockchain telah meletakkan dasar yang kuat untuk perkembangan jangka panjang jaringan TON. Selain itu, tim TonBit juga terus berupaya di bidang keamanan arsitektur jaringan, perlindungan data pengguna, dan peningkatan keamanan dalam skenario aplikasi blockchain. Ke depan, TonBit akan terus mendorong kemajuan teknologi keamanan melalui inovasi, memberikan dukungan dan jaminan tanpa henti untuk ekosistem TON dan seluruh industri blockchain. Penemuan kerentanan ini dan upaya perbaikan yang dilakukan telah mendapat pengakuan tinggi dari TON resmi, semakin memperkuat posisi TonBit dalam bidang keamanan blockchain, serta menunjukkan komitmen teguhnya terhadap pengembangan ekosistem desentralisasi.

Situs resmi TonBit: https://www.tonbit.xyz/

Twitter resmi TonBit: https://x.com/tonbit_

Telegram: https://t.me/BitsLabHQ

Linkedin: https://www.linkedin.com/company/tonbit-team/

Blog: https://www.tonbit.xyz/#blogs

Kontak permintaan audit Telegram: @starchou