Sebelumnya, tim CertiK menemukan serangkaian kerentanan denial-of-service di blockchain Sui. Di antara kerentanan ini, kerentanan baru dan berdampak tinggi menonjol. Kerentanan ini dapat menyebabkan node jaringan Sui tidak dapat memproses transaksi baru, dan efeknya setara dengan penghentian total seluruh jaringan.
Baru Senin lalu, CertiK menerima hadiah bug sebesar $500.000 dari SUI karena menemukan kerentanan keamanan utama ini. CoinDesk, media otoritatif di industri AS, melaporkan acara tersebut, dan kemudian media besar juga merilis berita terkait setelah laporannya.
Kerentanan keamanan ini dengan jelas disebut "Roda Hamster": metode serangannya yang unik berbeda dari serangan yang diketahui saat ini. Penyerang hanya perlu mengirimkan muatan sekitar 100 byte untuk memicu loop tak terbatas di node verifikasi Sui. , membuatnya tidak responsif ke transaksi baru.
Selain itu, kerusakan akibat serangan dapat berlanjut setelah jaringan dihidupkan ulang, dan dapat disebarkan secara otomatis di jaringan Sui, membuat semua node tidak dapat memproses transaksi baru seperti hamster yang berjalan tanpa henti di atas roda. Oleh karena itu, kami menyebut jenis serangan unik ini sebagai serangan "roda hamster".
Setelah menemukan bug tersebut, CertiK melaporkannya ke Sui melalui program bug bounty milik Sui. Sui juga merespons secara efektif pada kali pertama, mengonfirmasi keseriusan kerentanan, dan secara aktif mengambil tindakan yang sesuai untuk memperbaiki masalah sebelum peluncuran mainnet. Selain memperbaiki kerentanan khusus ini, Sui juga menerapkan mitigasi pencegahan untuk mengurangi potensi kerusakan yang dapat ditimbulkan oleh kerentanan ini.
Untuk berterima kasih kepada tim CertiK atas pengungkapan tanggung jawab mereka, Sui memberi hadiah $500.000 kepada tim CertiK.
Rincian kerentanan kritis ini akan diungkapkan pada tingkat teknis di bawah ini, dan akar penyebab serta dampak potensial dari kerentanan tersebut akan diklarifikasi.
Penjelasan Kerentanan
Peran kunci validator di Sui
Untuk rantai blok berdasarkan bahasa Pindah seperti Sui dan Aptos, mekanisme perlindungan untuk mencegah serangan payload berbahaya terutama adalah teknologi verifikasi statis. Melalui teknologi verifikasi statis, Sui dapat memeriksa validitas muatan yang diajukan oleh pengguna sebelum kontrak diterbitkan atau ditingkatkan. Validator menyediakan serangkaian checker untuk memastikan kebenaran struktur dan semantik.Hanya setelah melewati verifikasi cek, kontrak akan masuk ke mesin virtual Move untuk dieksekusi.
Ancaman Muatan Berbahaya di Rantai Pindah
Rantai Sui menyediakan satu set model penyimpanan dan antarmuka baru di atas mesin virtual Move asli, sehingga Sui memiliki versi khusus dari mesin virtual Move. Untuk mendukung penyimpanan primitif baru, Sui selanjutnya memperkenalkan serangkaian metode pemeriksaan tambahan dan khusus untuk verifikasi keamanan muatan yang tidak tepercaya, seperti keamanan objek dan fungsi akses penyimpanan global. Pemeriksaan khusus ini sesuai dengan fitur unik Sui, jadi kami menyebut pemeriksaan khusus ini sebagai validator Sui.
Perintah Sui untuk memeriksa muatan
Seperti yang ditunjukkan pada gambar di atas, sebagian besar pemeriksaan di pemverifikasi melakukan verifikasi keamanan struktural terhadap CompiledModule (mewakili eksekusi payload kontrak yang disediakan pengguna). Misalnya, gunakan "Pemeriksa Duplikat" untuk memastikan bahwa tidak ada entri duplikat dalam muatan waktu proses; gunakan "Pemeriksa Batas" untuk memastikan bahwa panjang setiap bidang dalam muatan waktu proses berada dalam batas entri maksimum yang diizinkan.
Selain pemeriksaan struktural, pemeriksaan statis pemverifikasi masih memerlukan metode analisis yang lebih kompleks untuk memastikan kekokohan muatan yang tidak dipercaya pada tingkat semantik.
Pelajari tentang juru bahasa abstrak Move:
Analisis Linear dan Iteratif
Interpreter abstrak yang disediakan oleh Move adalah kerangka kerja yang dirancang khusus untuk melakukan analisis keamanan kompleks pada bytecode melalui interpretasi abstrak. Mekanisme ini membuat proses verifikasi lebih terperinci dan akurat, dan setiap validator diizinkan untuk menentukan keadaan abstrak unik mereka untuk dianalisis.
Saat start-up, interpreter abstrak membuat grafik aliran kontrol (CFG) dari modul yang dikompilasi. Setiap blok dasar dalam CFG ini mempertahankan serangkaian status, "status pre-order" dan "status pasca-order". "Status pre-order" memberikan gambaran tentang status program sebelum eksekusi blok dasar, sedangkan "status pasca-order" memberikan deskripsi status program setelah eksekusi blok dasar.
Ketika penafsir abstrak tidak menemukan jumpback (atau loop) dalam grafik aliran kontrol, itu mengikuti prinsip eksekusi linier sederhana: setiap blok dasar dianalisis secara bergantian, dan instruksi sebelumnya dihitung sesuai dengan semantik dari setiap instruksi di blok Status berurutan dan status pasca-berurutan. Hasilnya adalah snapshot akurat dari status setiap blok dasar selama eksekusi program, membantu memverifikasi properti keamanan program.
Alur kerja juru bahasa abstrak Pindahkan
Namun, prosesnya menjadi lebih rumit ketika ada loop dalam aliran kontrol. Munculnya siklus berarti bahwa grafik aliran kontrol berisi tepi lompat-balik Sumber tepi lompat-balik sesuai dengan keadaan selanjutnya dari blok dasar saat ini, dan blok dasar target (kepala lingkaran) dari lompatan- back edge adalah analisis sebelumnya Oleh karena itu, interpreter abstrak perlu menggabungkan status dari dua blok dasar yang terkait dengan jumpback dengan hati-hati.
Jika status gabungan ditemukan berbeda dari status preorder yang ada dari blok dasar kepala loop, interpreter abstrak memperbarui status blok dasar kepala loop dan memulai kembali analisis mulai dari blok dasar ini. Proses analisis iteratif ini akan berlanjut hingga loop pre-state stabil. Dengan kata lain, proses ini diulangi sampai keadaan preorder blok dasar loop head tidak lagi berubah di antara iterasi. Mencapai titik tetap menunjukkan bahwa analisis siklus selesai.
Validator Sui IDLeak:
Analisis Interpretasi Abstrak yang Disesuaikan
Berbeda dengan desain Move yang asli, platform blockchain Sui memperkenalkan model penyimpanan global yang berpusat pada "tujuan" yang unik. Fitur penting dari model ini adalah: setiap struktur data dengan atribut kunci (disimpan di rantai sebagai indeks) harus memiliki tipe ID sebagai kolom pertama dari struktur. Bidang ID tidak dapat diubah dan tidak dapat ditransfer ke objek lain, karena setiap objek harus memiliki ID unik global. Untuk memastikan properti ini, Sui membuat satu set logika analisis khusus di atas penafsir abstrak.
Pemverifikasi IDLeak, juga dikenal sebagai id_leak_verifier, bekerja bersama dengan penerjemah abstrak untuk analisis. Ia memiliki AbstractDomain uniknya sendiri, yang disebut AbstractState. Setiap AbstractState terdiri dari AbstractValue yang sesuai dengan beberapa variabel lokal. Status setiap variabel lokal dipantau oleh AbstractValue untuk melacak apakah variabel ID baru.
Selama proses pengemasan struktur, validator IDLeak hanya mengizinkan pengemasan ID baru ke dalam struktur. Dengan mengabstraksi analisis interpretasi, validator IDLeak dapat melacak status aliran data lokal secara mendalam untuk memastikan bahwa tidak ada ID yang ada yang ditransfer ke objek struct lainnya.
Masalah inkonsistensi pemeliharaan status validator Sui IDLeak
Validator IDLeak terintegrasi dengan interpreter abstrak Move dengan mengimplementasikan fungsi AbstractState::join. Fungsi ini memainkan peran integral dalam manajemen negara, terutama dalam menggabungkan dan memperbarui nilai-nilai negara.
Periksa fungsi-fungsi ini secara rinci untuk memahami operasinya:
Di AbstractState::join, fungsi mengambil AbstractState lain sebagai input dan mencoba menggabungkan status lokalnya dengan status lokal objek saat ini. Untuk setiap variabel lokal di status masukan, ini membandingkan nilai variabel tersebut dengan nilai saat ini di status lokal (default ke AbstractValue::Other jika tidak ditemukan). Jika kedua nilai tidak sama, itu akan menetapkan bendera "berubah" sebagai dasar apakah hasil penggabungan status akhir telah berubah, dan memperbarui nilai variabel lokal di status lokal dengan memanggil AbstractValue::join.
Di AbstractValue::join, fungsi membandingkan nilainya dengan AbstractValue lainnya. Jika mereka sama, itu akan mengembalikan nilai yang diteruskan. Jika tidak sama, kembalikan AbstractValue::Other.
Namun, logika pemeliharaan status ini mengandung masalah inkonsistensi yang tersembunyi. Meskipun AbstractState::join akan mengembalikan hasil yang menunjukkan bahwa status gabungan telah berubah (JoinResult::Changed) berdasarkan perbedaan antara nilai baru dan lama, nilai status gabungan yang diperbarui mungkin tetap tidak berubah.
Masalah inkonsistensi ini disebabkan oleh urutan operasi: keputusan untuk mengubah status di AbstractState::join terjadi sebelum pembaruan status (AbstractValue::join), dan keputusan ini tidak mencerminkan hasil pembaruan status sebenarnya.
Selain itu, di AbstractValue::join, AbstractValue::Other memainkan peran yang menentukan dalam hasil penggabungan. Misalnya, jika nilai lama adalah AbstractValue::Other dan nilai baru adalah AbstractValue::Fresh, nilai status yang diperbarui masih AbstractValue::Other, meskipun nilai lama dan baru berbeda, status itu sendiri tetap tidak berubah setelah pembaruan.
Contoh: Inkoherensi Koneksi Stateful
Ini menimbulkan ketidakkonsistenan: hasil penggabungan status blok dasar dianggap "berubah", tetapi nilai status gabungan itu sendiri tidak berubah. Dalam proses analisis interpretasi abstrak, inkonsistensi semacam itu dapat menimbulkan konsekuensi serius. Kami meninjau perilaku juru bahasa abstrak saat siklus terjadi dalam grafik aliran kontrol (CFG):
Ketika sebuah loop ditemukan, interpreter abstrak menggunakan metode analisis iteratif untuk menggabungkan status blok dasar target lompatan dan blok dasar saat ini. Jika status gabungan berubah, interpreter abstrak akan menganalisis ulang mulai dari target lompatan.
Namun, jika operasi penggabungan analisis interpretasi abstrak keliru menandai hasil penggabungan negara sebagai "perubahan", padahal sebenarnya nilai variabel internal negara tidak berubah, itu akan mengarah pada analisis ulang tanpa akhir, menghasilkan putaran tak terbatas.
Eksploitasi Inkonsistensi Lebih Lanjut
Memicu infinite loop di validator Sui IDLeak
Memanfaatkan ketidakkonsistenan ini, penyerang dapat membuat grafik aliran kontrol berbahaya yang mengelabui validator IDLeak ke loop tak terbatas. Grafik aliran kontrol yang dibangun dengan hati-hati ini terdiri dari tiga blok dasar: BB1 dan BB2, BB3. Perlu dicatat bahwa kami sengaja memperkenalkan back jump edge dari BB3 ke BB2 untuk membuat loop.
Status CFG+ berbahaya dapat menyebabkan loop tak terbatas internal di validator IDLeak
Prosesnya dimulai dengan BB2, di mana AbstractValue dari variabel lokal tertentu diatur ke ::Other. Setelah menjalankan BB2, aliran ditransfer ke BB3 di mana variabel yang sama diatur ke ::Fresh. Di ujung BB3 ada back jump edge, lompat ke BB2.
Inkonsistensi yang disebutkan di atas memainkan peran kunci dalam interpretasi abstrak dari contoh ini. Saat back jump edge diproses, interpreter abstrak mencoba menghubungkan status postorder BB3 (dengan variabel "::Fresh") dengan status preorder BB2 (dengan variabel "::Other"). Fungsi AbstractState::join memperhatikan perbedaan antara nilai lama dan baru dan menyetel bendera "ubah" untuk menunjukkan bahwa BB2 perlu dianalisis ulang.
Namun, perilaku dominan "::Other" di AbstractValue::join berarti bahwa setelah AbstractValue digabungkan, nilai sebenarnya dari variabel status BB2 masih "::Other", dan hasil penggabungan status tidak berubah .
Jadi, begitu proses siklus ini dimulai, yaitu saat validator terus menganalisis ulang BB2 dan semua node blok dasar penggantinya (dalam hal ini BB3), proses ini berlanjut tanpa batas. Infinite loop menggunakan semua siklus CPU yang tersedia, membuatnya tidak dapat memproses dan merespons transaksi baru, yang tetap ada saat validator dimulai ulang.
Dengan mengeksploitasi kerentanan ini, node validasi berjalan tanpa henti seperti hamster di atas roda dalam putaran tak terbatas, tidak dapat memproses transaksi baru. Oleh karena itu, kami menyebut jenis serangan unik ini sebagai serangan "roda hamster".
Serangan “roda hamster” dapat secara efektif menghentikan validator Sui, yang pada gilirannya dapat melumpuhkan seluruh jaringan Sui.
Setelah memahami penyebab kerentanan dan proses pemicuan, kami membuat contoh konkret dengan menggunakan simulasi Move bytecode berikut dan berhasil memicu kerentanan dalam simulasi di lingkungan nyata:
Contoh ini menunjukkan cara memicu kerentanan di lingkungan nyata melalui bytecode yang dibuat dengan hati-hati. Secara khusus, penyerang dapat memicu loop tak terbatas di validator IDLeak, menghabiskan semua siklus CPU dari node Sui dengan muatan hanya sekitar 100 byte, secara efektif mencegah pemrosesan transaksi baru dan menyebabkan penolakan layanan di jaringan Sui.
Serangan "Roda Hamster" terus merusak jaringan Sui
Program hadiah bug Sui memiliki peraturan ketat tentang penilaian tingkat kerentanan, terutama berdasarkan tingkat kerusakan pada seluruh jaringan. Kerentanan yang memenuhi peringkat "kritis" harus menutup seluruh jaringan dan secara efektif mencegah konfirmasi transaksi baru, dan memerlukan garpu keras untuk memperbaiki masalah; kerentanan (sedang)” atau “berisiko tinggi (tinggi)”.
Kerentanan "roda hamster" yang ditemukan oleh tim CertiK Skyfall dapat mematikan seluruh jaringan Sui, dan memerlukan rilis resmi versi baru untuk peningkatan dan perbaikan. Sui akhirnya menilai kerentanan sebagai "Kritis" berdasarkan kekritisannya. Untuk lebih memahami dampak serius yang disebabkan oleh serangan "roda hamster", kami perlu memahami arsitektur kompleks sistem backend Sui, terutama seluruh proses penerbitan atau pemutakhiran transaksi pada rantai.
Tinjauan interaksi untuk mengirimkan transaksi di Sui
Awalnya, transaksi pengguna dikirimkan melalui RPC front-end dan diteruskan ke layanan back-end setelah verifikasi dasar. Layanan backend Sui bertanggung jawab untuk memvalidasi muatan transaksi masuk lebih lanjut. Setelah berhasil memverifikasi tanda tangan pengguna, transaksi diubah menjadi sertifikat transaksi (berisi informasi transaksi dan tanda tangan Sui).
Sertifikat transaksi ini merupakan bagian mendasar dari pengoperasian jaringan Sui dan dapat disebarluaskan di antara berbagai simpul verifikasi dalam jaringan. Untuk transaksi pembuatan/peningkatan kontrak, sebelum dapat diunggah ke rantai, simpul verifikasi akan memanggil pemverifikasi Sui untuk memeriksa dan memverifikasi validitas struktur/semantik kontrak dari sertifikat ini. Selama tahap verifikasi kritis inilah kerentanan "loop tak terbatas" dapat dipicu dan dieksploitasi.
Ketika kerentanan dipicu, itu menyebabkan proses verifikasi terganggu tanpa batas waktu, secara efektif menghambat kemampuan sistem untuk memproses transaksi baru dan menyebabkan jaringan mati sepenuhnya. Untuk menambah penghinaan terhadap cedera, situasi tetap ada setelah node dimulai ulang, yang berarti mitigasi tradisional jauh dari memadai. Setelah kerentanan dipicu, akan ada "kerusakan terus menerus" dan meninggalkan dampak yang bertahan lama di seluruh jaringan Sui.
Solusi Sui
Setelah umpan balik dari CertiK, Sui mengonfirmasi kerentanan tersebut secara tepat waktu dan merilis perbaikan untuk mengatasi kelemahan kritis tersebut. Perbaikan ini memastikan konsistensi antara perubahan status dan flag setelah perubahan, menghilangkan efek kritis dari serangan "roda hamster".
Untuk menghapus ketidakkonsistenan yang disebutkan di atas, perbaikan Sui menyertakan perubahan kecil namun penting pada fungsi AbstractState::join. Patch ini menghapus logika penentuan hasil penggabungan negara sebelum mengeksekusi AbstractValue::join. Sebagai gantinya, jalankan fungsi AbstractValue::join untuk penggabungan negara terlebih dahulu, dan atur penggabungan dengan membandingkan hasil pembaruan akhir dengan nilai negara asli (lama _value) Bendera untuk perubahan.
Dengan cara ini, hasil penggabungan status akan konsisten dengan hasil pembaruan yang sebenarnya, dan loop tak terbatas tidak akan terjadi selama proses analisis.
Selain memperbaiki kerentanan khusus ini, Sui juga menerapkan mitigasi untuk mengurangi dampak kerentanan validator di masa mendatang. Menurut tanggapan Sui dalam laporan bug, mitigasi melibatkan fitur yang disebut Denylist.
"Namun, validator memiliki file konfigurasi node yang memungkinkan mereka untuk sementara menolak kelas transaksi tertentu. Konfigurasi ini dapat digunakan untuk sementara menonaktifkan pemrosesan rilis dan pemutakhiran paket. Karena bug ini menjalankan Sui sebelum menandatangani rilis atau pemutakhiran paket tx validator, sementara daftar yang ditolak akan menghentikan validator agar tidak berjalan dan menghapus tx berbahaya, sementara menolak jenis tx ini adalah mitigasi yang 100% efektif (walaupun untuk sementara akan mengganggu layanan bagi orang yang mencoba merilis atau memutakhirkan kode).
Kebetulan, kami telah memiliki file konfigurasi daftar tolak TX ini untuk sementara waktu sekarang, tetapi kami juga telah menambahkan mekanisme serupa untuk sertifikat sebagai tindak lanjut mitigasi untuk kerentanan "loop validator" yang Anda laporkan sebelumnya. Dengan mekanisme ini, kami akan memiliki lebih banyak fleksibilitas terhadap serangan ini: kami akan menggunakan konfigurasi daftar penolakan sertifikat untuk membuat validator melupakan sertifikat buruk (memutus loop tak terbatas), dan konfigurasi daftar penolakan TX untuk melarang penerbitan/peningkatan, sehingga mencegah pembuatan transaksi serangan berbahaya baru. Terima kasih telah membuat kami memikirkan hal ini!
Validator memiliki "kutu" dalam jumlah terbatas (berbeda dengan gas) untuk verifikasi bytecode sebelum menandatangani transaksi, dan jika semua bytecode yang dikeluarkan dalam transaksi tidak dapat diverifikasi dalam banyak tick ini, validator akan menolak untuk menandatangani transaksi, mencegah dari eksekusi di jaringan. Sebelumnya, pengukuran hanya diterapkan pada kumpulan pass validator kompleks yang dipilih. Untuk mengatasi hal ini, kami memperluas pengukuran ke setiap validator untuk menjamin batasan pada pekerjaan yang dilakukan oleh validator selama proses validasi setiap tick. Kami juga memperbaiki potensi bug infinite loop di validator kebocoran ID. "
--Penjelasan dari pengembang Sui tentang perbaikan bug
Secara keseluruhan, Denylist memungkinkan validator untuk sementara menghindari eksploitasi kerentanan di validator dan secara efektif mencegah potensi kerusakan yang disebabkan oleh beberapa transaksi berbahaya dengan menonaktifkan proses rilis atau pemutakhiran. Saat tindakan mitigasi Denylist berlaku, node memastikan bahwa mereka dapat terus bekerja dengan mengorbankan fungsi kontrak penerbitan/pembaruan mereka sendiri.
Meringkaskan
Dalam artikel ini, kami membagikan detail teknis dari serangan "Hamster Wheel" yang ditemukan oleh tim CertiK Skyfall, menjelaskan bagaimana jenis serangan baru ini mengeksploitasi kerentanan utama untuk menyebabkan jaringan Sui mati total. Selain itu, kami juga dengan hati-hati mempelajari tanggapan tepat waktu Sui untuk memperbaiki masalah kritis ini, dan membagikan perbaikan kerentanan dan metode mitigasi selanjutnya untuk kerentanan serupa.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
Detail teknis "roda hamster" kerentanan terbaru Sui dan analisis mendalam
Sebelumnya, tim CertiK menemukan serangkaian kerentanan denial-of-service di blockchain Sui. Di antara kerentanan ini, kerentanan baru dan berdampak tinggi menonjol. Kerentanan ini dapat menyebabkan node jaringan Sui tidak dapat memproses transaksi baru, dan efeknya setara dengan penghentian total seluruh jaringan.
Baru Senin lalu, CertiK menerima hadiah bug sebesar $500.000 dari SUI karena menemukan kerentanan keamanan utama ini. CoinDesk, media otoritatif di industri AS, melaporkan acara tersebut, dan kemudian media besar juga merilis berita terkait setelah laporannya.
Kerentanan keamanan ini dengan jelas disebut "Roda Hamster": metode serangannya yang unik berbeda dari serangan yang diketahui saat ini. Penyerang hanya perlu mengirimkan muatan sekitar 100 byte untuk memicu loop tak terbatas di node verifikasi Sui. , membuatnya tidak responsif ke transaksi baru.
Selain itu, kerusakan akibat serangan dapat berlanjut setelah jaringan dihidupkan ulang, dan dapat disebarkan secara otomatis di jaringan Sui, membuat semua node tidak dapat memproses transaksi baru seperti hamster yang berjalan tanpa henti di atas roda. Oleh karena itu, kami menyebut jenis serangan unik ini sebagai serangan "roda hamster".
Setelah menemukan bug tersebut, CertiK melaporkannya ke Sui melalui program bug bounty milik Sui. Sui juga merespons secara efektif pada kali pertama, mengonfirmasi keseriusan kerentanan, dan secara aktif mengambil tindakan yang sesuai untuk memperbaiki masalah sebelum peluncuran mainnet. Selain memperbaiki kerentanan khusus ini, Sui juga menerapkan mitigasi pencegahan untuk mengurangi potensi kerusakan yang dapat ditimbulkan oleh kerentanan ini.
Untuk berterima kasih kepada tim CertiK atas pengungkapan tanggung jawab mereka, Sui memberi hadiah $500.000 kepada tim CertiK.
Rincian kerentanan kritis ini akan diungkapkan pada tingkat teknis di bawah ini, dan akar penyebab serta dampak potensial dari kerentanan tersebut akan diklarifikasi.
Penjelasan Kerentanan
Peran kunci validator di Sui
Untuk rantai blok berdasarkan bahasa Pindah seperti Sui dan Aptos, mekanisme perlindungan untuk mencegah serangan payload berbahaya terutama adalah teknologi verifikasi statis. Melalui teknologi verifikasi statis, Sui dapat memeriksa validitas muatan yang diajukan oleh pengguna sebelum kontrak diterbitkan atau ditingkatkan. Validator menyediakan serangkaian checker untuk memastikan kebenaran struktur dan semantik.Hanya setelah melewati verifikasi cek, kontrak akan masuk ke mesin virtual Move untuk dieksekusi.
Ancaman Muatan Berbahaya di Rantai Pindah
Rantai Sui menyediakan satu set model penyimpanan dan antarmuka baru di atas mesin virtual Move asli, sehingga Sui memiliki versi khusus dari mesin virtual Move. Untuk mendukung penyimpanan primitif baru, Sui selanjutnya memperkenalkan serangkaian metode pemeriksaan tambahan dan khusus untuk verifikasi keamanan muatan yang tidak tepercaya, seperti keamanan objek dan fungsi akses penyimpanan global. Pemeriksaan khusus ini sesuai dengan fitur unik Sui, jadi kami menyebut pemeriksaan khusus ini sebagai validator Sui.
Perintah Sui untuk memeriksa muatan
Seperti yang ditunjukkan pada gambar di atas, sebagian besar pemeriksaan di pemverifikasi melakukan verifikasi keamanan struktural terhadap CompiledModule (mewakili eksekusi payload kontrak yang disediakan pengguna). Misalnya, gunakan "Pemeriksa Duplikat" untuk memastikan bahwa tidak ada entri duplikat dalam muatan waktu proses; gunakan "Pemeriksa Batas" untuk memastikan bahwa panjang setiap bidang dalam muatan waktu proses berada dalam batas entri maksimum yang diizinkan.
Selain pemeriksaan struktural, pemeriksaan statis pemverifikasi masih memerlukan metode analisis yang lebih kompleks untuk memastikan kekokohan muatan yang tidak dipercaya pada tingkat semantik.
Pelajari tentang juru bahasa abstrak Move:
Analisis Linear dan Iteratif
Interpreter abstrak yang disediakan oleh Move adalah kerangka kerja yang dirancang khusus untuk melakukan analisis keamanan kompleks pada bytecode melalui interpretasi abstrak. Mekanisme ini membuat proses verifikasi lebih terperinci dan akurat, dan setiap validator diizinkan untuk menentukan keadaan abstrak unik mereka untuk dianalisis.
Saat start-up, interpreter abstrak membuat grafik aliran kontrol (CFG) dari modul yang dikompilasi. Setiap blok dasar dalam CFG ini mempertahankan serangkaian status, "status pre-order" dan "status pasca-order". "Status pre-order" memberikan gambaran tentang status program sebelum eksekusi blok dasar, sedangkan "status pasca-order" memberikan deskripsi status program setelah eksekusi blok dasar.
Ketika penafsir abstrak tidak menemukan jumpback (atau loop) dalam grafik aliran kontrol, itu mengikuti prinsip eksekusi linier sederhana: setiap blok dasar dianalisis secara bergantian, dan instruksi sebelumnya dihitung sesuai dengan semantik dari setiap instruksi di blok Status berurutan dan status pasca-berurutan. Hasilnya adalah snapshot akurat dari status setiap blok dasar selama eksekusi program, membantu memverifikasi properti keamanan program.
Alur kerja juru bahasa abstrak Pindahkan
Namun, prosesnya menjadi lebih rumit ketika ada loop dalam aliran kontrol. Munculnya siklus berarti bahwa grafik aliran kontrol berisi tepi lompat-balik Sumber tepi lompat-balik sesuai dengan keadaan selanjutnya dari blok dasar saat ini, dan blok dasar target (kepala lingkaran) dari lompatan- back edge adalah analisis sebelumnya Oleh karena itu, interpreter abstrak perlu menggabungkan status dari dua blok dasar yang terkait dengan jumpback dengan hati-hati.
Jika status gabungan ditemukan berbeda dari status preorder yang ada dari blok dasar kepala loop, interpreter abstrak memperbarui status blok dasar kepala loop dan memulai kembali analisis mulai dari blok dasar ini. Proses analisis iteratif ini akan berlanjut hingga loop pre-state stabil. Dengan kata lain, proses ini diulangi sampai keadaan preorder blok dasar loop head tidak lagi berubah di antara iterasi. Mencapai titik tetap menunjukkan bahwa analisis siklus selesai.
Validator Sui IDLeak:
Analisis Interpretasi Abstrak yang Disesuaikan
Berbeda dengan desain Move yang asli, platform blockchain Sui memperkenalkan model penyimpanan global yang berpusat pada "tujuan" yang unik. Fitur penting dari model ini adalah: setiap struktur data dengan atribut kunci (disimpan di rantai sebagai indeks) harus memiliki tipe ID sebagai kolom pertama dari struktur. Bidang ID tidak dapat diubah dan tidak dapat ditransfer ke objek lain, karena setiap objek harus memiliki ID unik global. Untuk memastikan properti ini, Sui membuat satu set logika analisis khusus di atas penafsir abstrak.
Pemverifikasi IDLeak, juga dikenal sebagai id_leak_verifier, bekerja bersama dengan penerjemah abstrak untuk analisis. Ia memiliki AbstractDomain uniknya sendiri, yang disebut AbstractState. Setiap AbstractState terdiri dari AbstractValue yang sesuai dengan beberapa variabel lokal. Status setiap variabel lokal dipantau oleh AbstractValue untuk melacak apakah variabel ID baru.
Selama proses pengemasan struktur, validator IDLeak hanya mengizinkan pengemasan ID baru ke dalam struktur. Dengan mengabstraksi analisis interpretasi, validator IDLeak dapat melacak status aliran data lokal secara mendalam untuk memastikan bahwa tidak ada ID yang ada yang ditransfer ke objek struct lainnya.
Masalah inkonsistensi pemeliharaan status validator Sui IDLeak
Validator IDLeak terintegrasi dengan interpreter abstrak Move dengan mengimplementasikan fungsi AbstractState::join. Fungsi ini memainkan peran integral dalam manajemen negara, terutama dalam menggabungkan dan memperbarui nilai-nilai negara.
Periksa fungsi-fungsi ini secara rinci untuk memahami operasinya:
Di AbstractState::join, fungsi mengambil AbstractState lain sebagai input dan mencoba menggabungkan status lokalnya dengan status lokal objek saat ini. Untuk setiap variabel lokal di status masukan, ini membandingkan nilai variabel tersebut dengan nilai saat ini di status lokal (default ke AbstractValue::Other jika tidak ditemukan). Jika kedua nilai tidak sama, itu akan menetapkan bendera "berubah" sebagai dasar apakah hasil penggabungan status akhir telah berubah, dan memperbarui nilai variabel lokal di status lokal dengan memanggil AbstractValue::join.
Di AbstractValue::join, fungsi membandingkan nilainya dengan AbstractValue lainnya. Jika mereka sama, itu akan mengembalikan nilai yang diteruskan. Jika tidak sama, kembalikan AbstractValue::Other.
Namun, logika pemeliharaan status ini mengandung masalah inkonsistensi yang tersembunyi. Meskipun AbstractState::join akan mengembalikan hasil yang menunjukkan bahwa status gabungan telah berubah (JoinResult::Changed) berdasarkan perbedaan antara nilai baru dan lama, nilai status gabungan yang diperbarui mungkin tetap tidak berubah.
Masalah inkonsistensi ini disebabkan oleh urutan operasi: keputusan untuk mengubah status di AbstractState::join terjadi sebelum pembaruan status (AbstractValue::join), dan keputusan ini tidak mencerminkan hasil pembaruan status sebenarnya.
Selain itu, di AbstractValue::join, AbstractValue::Other memainkan peran yang menentukan dalam hasil penggabungan. Misalnya, jika nilai lama adalah AbstractValue::Other dan nilai baru adalah AbstractValue::Fresh, nilai status yang diperbarui masih AbstractValue::Other, meskipun nilai lama dan baru berbeda, status itu sendiri tetap tidak berubah setelah pembaruan.
Contoh: Inkoherensi Koneksi Stateful
Ini menimbulkan ketidakkonsistenan: hasil penggabungan status blok dasar dianggap "berubah", tetapi nilai status gabungan itu sendiri tidak berubah. Dalam proses analisis interpretasi abstrak, inkonsistensi semacam itu dapat menimbulkan konsekuensi serius. Kami meninjau perilaku juru bahasa abstrak saat siklus terjadi dalam grafik aliran kontrol (CFG):
Ketika sebuah loop ditemukan, interpreter abstrak menggunakan metode analisis iteratif untuk menggabungkan status blok dasar target lompatan dan blok dasar saat ini. Jika status gabungan berubah, interpreter abstrak akan menganalisis ulang mulai dari target lompatan.
Namun, jika operasi penggabungan analisis interpretasi abstrak keliru menandai hasil penggabungan negara sebagai "perubahan", padahal sebenarnya nilai variabel internal negara tidak berubah, itu akan mengarah pada analisis ulang tanpa akhir, menghasilkan putaran tak terbatas.
Eksploitasi Inkonsistensi Lebih Lanjut
Memicu infinite loop di validator Sui IDLeak
Memanfaatkan ketidakkonsistenan ini, penyerang dapat membuat grafik aliran kontrol berbahaya yang mengelabui validator IDLeak ke loop tak terbatas. Grafik aliran kontrol yang dibangun dengan hati-hati ini terdiri dari tiga blok dasar: BB1 dan BB2, BB3. Perlu dicatat bahwa kami sengaja memperkenalkan back jump edge dari BB3 ke BB2 untuk membuat loop.
Status CFG+ berbahaya dapat menyebabkan loop tak terbatas internal di validator IDLeak
Prosesnya dimulai dengan BB2, di mana AbstractValue dari variabel lokal tertentu diatur ke ::Other. Setelah menjalankan BB2, aliran ditransfer ke BB3 di mana variabel yang sama diatur ke ::Fresh. Di ujung BB3 ada back jump edge, lompat ke BB2.
Inkonsistensi yang disebutkan di atas memainkan peran kunci dalam interpretasi abstrak dari contoh ini. Saat back jump edge diproses, interpreter abstrak mencoba menghubungkan status postorder BB3 (dengan variabel "::Fresh") dengan status preorder BB2 (dengan variabel "::Other"). Fungsi AbstractState::join memperhatikan perbedaan antara nilai lama dan baru dan menyetel bendera "ubah" untuk menunjukkan bahwa BB2 perlu dianalisis ulang.
Namun, perilaku dominan "::Other" di AbstractValue::join berarti bahwa setelah AbstractValue digabungkan, nilai sebenarnya dari variabel status BB2 masih "::Other", dan hasil penggabungan status tidak berubah .
Jadi, begitu proses siklus ini dimulai, yaitu saat validator terus menganalisis ulang BB2 dan semua node blok dasar penggantinya (dalam hal ini BB3), proses ini berlanjut tanpa batas. Infinite loop menggunakan semua siklus CPU yang tersedia, membuatnya tidak dapat memproses dan merespons transaksi baru, yang tetap ada saat validator dimulai ulang.
Dengan mengeksploitasi kerentanan ini, node validasi berjalan tanpa henti seperti hamster di atas roda dalam putaran tak terbatas, tidak dapat memproses transaksi baru. Oleh karena itu, kami menyebut jenis serangan unik ini sebagai serangan "roda hamster".
Serangan “roda hamster” dapat secara efektif menghentikan validator Sui, yang pada gilirannya dapat melumpuhkan seluruh jaringan Sui.
Setelah memahami penyebab kerentanan dan proses pemicuan, kami membuat contoh konkret dengan menggunakan simulasi Move bytecode berikut dan berhasil memicu kerentanan dalam simulasi di lingkungan nyata:
Contoh ini menunjukkan cara memicu kerentanan di lingkungan nyata melalui bytecode yang dibuat dengan hati-hati. Secara khusus, penyerang dapat memicu loop tak terbatas di validator IDLeak, menghabiskan semua siklus CPU dari node Sui dengan muatan hanya sekitar 100 byte, secara efektif mencegah pemrosesan transaksi baru dan menyebabkan penolakan layanan di jaringan Sui.
Serangan "Roda Hamster" terus merusak jaringan Sui
Program hadiah bug Sui memiliki peraturan ketat tentang penilaian tingkat kerentanan, terutama berdasarkan tingkat kerusakan pada seluruh jaringan. Kerentanan yang memenuhi peringkat "kritis" harus menutup seluruh jaringan dan secara efektif mencegah konfirmasi transaksi baru, dan memerlukan garpu keras untuk memperbaiki masalah; kerentanan (sedang)” atau “berisiko tinggi (tinggi)”.
Kerentanan "roda hamster" yang ditemukan oleh tim CertiK Skyfall dapat mematikan seluruh jaringan Sui, dan memerlukan rilis resmi versi baru untuk peningkatan dan perbaikan. Sui akhirnya menilai kerentanan sebagai "Kritis" berdasarkan kekritisannya. Untuk lebih memahami dampak serius yang disebabkan oleh serangan "roda hamster", kami perlu memahami arsitektur kompleks sistem backend Sui, terutama seluruh proses penerbitan atau pemutakhiran transaksi pada rantai.
Tinjauan interaksi untuk mengirimkan transaksi di Sui
Awalnya, transaksi pengguna dikirimkan melalui RPC front-end dan diteruskan ke layanan back-end setelah verifikasi dasar. Layanan backend Sui bertanggung jawab untuk memvalidasi muatan transaksi masuk lebih lanjut. Setelah berhasil memverifikasi tanda tangan pengguna, transaksi diubah menjadi sertifikat transaksi (berisi informasi transaksi dan tanda tangan Sui).
Sertifikat transaksi ini merupakan bagian mendasar dari pengoperasian jaringan Sui dan dapat disebarluaskan di antara berbagai simpul verifikasi dalam jaringan. Untuk transaksi pembuatan/peningkatan kontrak, sebelum dapat diunggah ke rantai, simpul verifikasi akan memanggil pemverifikasi Sui untuk memeriksa dan memverifikasi validitas struktur/semantik kontrak dari sertifikat ini. Selama tahap verifikasi kritis inilah kerentanan "loop tak terbatas" dapat dipicu dan dieksploitasi.
Ketika kerentanan dipicu, itu menyebabkan proses verifikasi terganggu tanpa batas waktu, secara efektif menghambat kemampuan sistem untuk memproses transaksi baru dan menyebabkan jaringan mati sepenuhnya. Untuk menambah penghinaan terhadap cedera, situasi tetap ada setelah node dimulai ulang, yang berarti mitigasi tradisional jauh dari memadai. Setelah kerentanan dipicu, akan ada "kerusakan terus menerus" dan meninggalkan dampak yang bertahan lama di seluruh jaringan Sui.
Solusi Sui
Setelah umpan balik dari CertiK, Sui mengonfirmasi kerentanan tersebut secara tepat waktu dan merilis perbaikan untuk mengatasi kelemahan kritis tersebut. Perbaikan ini memastikan konsistensi antara perubahan status dan flag setelah perubahan, menghilangkan efek kritis dari serangan "roda hamster".
Untuk menghapus ketidakkonsistenan yang disebutkan di atas, perbaikan Sui menyertakan perubahan kecil namun penting pada fungsi AbstractState::join. Patch ini menghapus logika penentuan hasil penggabungan negara sebelum mengeksekusi AbstractValue::join. Sebagai gantinya, jalankan fungsi AbstractValue::join untuk penggabungan negara terlebih dahulu, dan atur penggabungan dengan membandingkan hasil pembaruan akhir dengan nilai negara asli (lama _value) Bendera untuk perubahan.
Dengan cara ini, hasil penggabungan status akan konsisten dengan hasil pembaruan yang sebenarnya, dan loop tak terbatas tidak akan terjadi selama proses analisis.
Selain memperbaiki kerentanan khusus ini, Sui juga menerapkan mitigasi untuk mengurangi dampak kerentanan validator di masa mendatang. Menurut tanggapan Sui dalam laporan bug, mitigasi melibatkan fitur yang disebut Denylist.
"Namun, validator memiliki file konfigurasi node yang memungkinkan mereka untuk sementara menolak kelas transaksi tertentu. Konfigurasi ini dapat digunakan untuk sementara menonaktifkan pemrosesan rilis dan pemutakhiran paket. Karena bug ini menjalankan Sui sebelum menandatangani rilis atau pemutakhiran paket tx validator, sementara daftar yang ditolak akan menghentikan validator agar tidak berjalan dan menghapus tx berbahaya, sementara menolak jenis tx ini adalah mitigasi yang 100% efektif (walaupun untuk sementara akan mengganggu layanan bagi orang yang mencoba merilis atau memutakhirkan kode).
Kebetulan, kami telah memiliki file konfigurasi daftar tolak TX ini untuk sementara waktu sekarang, tetapi kami juga telah menambahkan mekanisme serupa untuk sertifikat sebagai tindak lanjut mitigasi untuk kerentanan "loop validator" yang Anda laporkan sebelumnya. Dengan mekanisme ini, kami akan memiliki lebih banyak fleksibilitas terhadap serangan ini: kami akan menggunakan konfigurasi daftar penolakan sertifikat untuk membuat validator melupakan sertifikat buruk (memutus loop tak terbatas), dan konfigurasi daftar penolakan TX untuk melarang penerbitan/peningkatan, sehingga mencegah pembuatan transaksi serangan berbahaya baru. Terima kasih telah membuat kami memikirkan hal ini!
Validator memiliki "kutu" dalam jumlah terbatas (berbeda dengan gas) untuk verifikasi bytecode sebelum menandatangani transaksi, dan jika semua bytecode yang dikeluarkan dalam transaksi tidak dapat diverifikasi dalam banyak tick ini, validator akan menolak untuk menandatangani transaksi, mencegah dari eksekusi di jaringan. Sebelumnya, pengukuran hanya diterapkan pada kumpulan pass validator kompleks yang dipilih. Untuk mengatasi hal ini, kami memperluas pengukuran ke setiap validator untuk menjamin batasan pada pekerjaan yang dilakukan oleh validator selama proses validasi setiap tick. Kami juga memperbaiki potensi bug infinite loop di validator kebocoran ID. "
--Penjelasan dari pengembang Sui tentang perbaikan bug
Secara keseluruhan, Denylist memungkinkan validator untuk sementara menghindari eksploitasi kerentanan di validator dan secara efektif mencegah potensi kerusakan yang disebabkan oleh beberapa transaksi berbahaya dengan menonaktifkan proses rilis atau pemutakhiran. Saat tindakan mitigasi Denylist berlaku, node memastikan bahwa mereka dapat terus bekerja dengan mengorbankan fungsi kontrak penerbitan/pembaruan mereka sendiri.
Meringkaskan
Dalam artikel ini, kami membagikan detail teknis dari serangan "Hamster Wheel" yang ditemukan oleh tim CertiK Skyfall, menjelaskan bagaimana jenis serangan baru ini mengeksploitasi kerentanan utama untuk menyebabkan jaringan Sui mati total. Selain itu, kami juga dengan hati-hati mempelajari tanggapan tepat waktu Sui untuk memperbaiki masalah kritis ini, dan membagikan perbaikan kerentanan dan metode mitigasi selanjutnya untuk kerentanan serupa.