Analisis Kerentanan Overflow Integer dalam Bahasa Move
Pendahuluan
Setelah melakukan penelitian mendalam tentang Aptos Moveevm, kami menemukan kerentanan overflow integer baru. Proses pemicu kerentanan ini cukup menarik, di bawah ini kami akan menganalisis kerentanan ini secara mendalam dan memperkenalkan beberapa pengetahuan latar belakang tentang bahasa Move. Melalui penjelasan dalam artikel ini, kami yakin Anda akan memiliki pemahaman yang lebih dalam tentang bahasa Move.
Bahasa Move akan memverifikasi unit kode sebelum mengeksekusi bytecode. Proses verifikasi dibagi menjadi 4 langkah, dan kerentanan ini muncul pada langkah reference_safety.
Keamanan Referensi dalam Move
Bahasa Move mendukung dua jenis referensi: referensi tidak berubah (&) dan referensi berubah (&mut). Referensi tidak berubah digunakan untuk membaca data dari struktur, sementara referensi berubah digunakan untuk memodifikasi data. Menggunakan jenis referensi yang tepat membantu menjaga keamanan dan mengidentifikasi modul pembacaan.
Dalam modul keamanan referensi Move, instruksi byte dari blok dasar dalam fungsi akan dipindai per unit fungsi untuk memverifikasi semua operasi referensi adalah sah. Proses utama untuk memverifikasi keamanan referensi mencakup langkah-langkah seperti mengeksekusi blok dasar, menghasilkan status pasca, menggabungkan status sebelumnya dan sesudah, dll.
Analisis Kerentanan
Kerentanan muncul dalam fungsi join_ yang mengacu pada modul keamanan. Ketika jumlah panjang parameter fungsi dan panjang variabel lokal lebih besar dari 256, penggunaan tipe u8 untuk merepresentasikan variabel lokal dapat menyebabkan overflow integer.
Meskipun Move memiliki proses untuk memverifikasi jumlah locals, modul check bounds hanya memverifikasi locals dan tidak termasuk panjang parameter. Sepertinya pengembang menyadari perlunya memeriksa jumlah parameter dan nilai lokal, tetapi kode hanya memverifikasi jumlah variabel lokal.
Dari overflow integer ke serangan DoS
Dengan memanfaatkan kerentanan integer overflow ini, penyerang dapat membuat blok kode loop yang mengubah status blok. Ketika fungsi execute_block dijalankan lagi, jika indeks yang perlu diakses oleh instruksi tidak ada dalam peta locals AbstractState yang baru, akan menyebabkan serangan DoS.
Dalam modul reference safety, opcode seperti MoveLoc/CopyLoc/FreeRef dapat memicu situasi ini. Misalnya, dalam fungsi copy_loc, jika LocalIndex tidak ada, maka akan menyebabkan panic, yang selanjutnya menyebabkan seluruh node crash.
Reproduksi Kerentanan
Anda dapat mereproduksi kerentanan ini di git dengan kode PoC berikut:
gerakkan
public fun test(a: u64, b: u64, c: u64, d: u64) {
let x = 0;
loop {
jika (x == 1) {
istirahat
};
x = x + 1;
}
}
Langkah-langkah untuk memicu DoS adalah sebagai berikut:
Pertama kali mengeksekusi fungsi execute_block, mengatur parameters dan locals keduanya menjadi SignatureIndex(0), yang mengakibatkan num_locals menjadi 264. Setelah menjalankan fungsi join_, panjang map locals baru menjadi 8.
Saat fungsi execute_block dieksekusi untuk kedua kalinya, instruksi pertama dari kode move yang dieksekusi adalah copyloc(57). Karena pada saat ini locals hanya memiliki panjang 8, offset 57 tidak ada, yang menyebabkan fungsi get(57).unwrap() mengembalikan None, yang akhirnya menyebabkan panic.
Ringkasan
Kerentanan ini menunjukkan bahwa tidak ada kode yang sepenuhnya aman. Meskipun bahasa Move melakukan pemeriksaan statis sebelum eksekusi kode, masih mungkin untuk dilalui oleh kerentanan overflow. Ini sekali lagi menekankan pentingnya audit kode.
Untuk bahasa Move, kami menyarankan untuk menambahkan lebih banyak kode pemeriksaan saat runtime untuk mencegah situasi yang tidak diinginkan. Saat ini, Move terutama melakukan pemeriksaan keamanan di tahap verifikasi, tetapi begitu verifikasi dilewati, kurangnya penguatan keamanan yang memadai di tahap eksekusi dapat menyebabkan masalah yang lebih serius.
Sebagai pemimpin penelitian keamanan bahasa Move, kami akan terus mendalami masalah keamanan Move dan membagikan lebih banyak temuan di masa mendatang.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
18 Suka
Hadiah
18
4
Posting ulang
Bagikan
Komentar
0/400
PretendingToReadDocs
· 08-15 17:34
move ini juga bisa bermasalah
Lihat AsliBalas0
WalletDetective
· 08-14 07:06
Setelah diperhatikan, celah ini cukup menarik.
Lihat AsliBalas0
ponzi_poet
· 08-14 07:00
apakah itu tulus atau hanya untuk menghasilkan uang move overflow
Analisis kerentanan integer overflow dalam bahasa Move: dari keamanan referensi ke serangan DoS
Analisis Kerentanan Overflow Integer dalam Bahasa Move
Pendahuluan
Setelah melakukan penelitian mendalam tentang Aptos Moveevm, kami menemukan kerentanan overflow integer baru. Proses pemicu kerentanan ini cukup menarik, di bawah ini kami akan menganalisis kerentanan ini secara mendalam dan memperkenalkan beberapa pengetahuan latar belakang tentang bahasa Move. Melalui penjelasan dalam artikel ini, kami yakin Anda akan memiliki pemahaman yang lebih dalam tentang bahasa Move.
Bahasa Move akan memverifikasi unit kode sebelum mengeksekusi bytecode. Proses verifikasi dibagi menjadi 4 langkah, dan kerentanan ini muncul pada langkah reference_safety.
Keamanan Referensi dalam Move
Bahasa Move mendukung dua jenis referensi: referensi tidak berubah (&) dan referensi berubah (&mut). Referensi tidak berubah digunakan untuk membaca data dari struktur, sementara referensi berubah digunakan untuk memodifikasi data. Menggunakan jenis referensi yang tepat membantu menjaga keamanan dan mengidentifikasi modul pembacaan.
Dalam modul keamanan referensi Move, instruksi byte dari blok dasar dalam fungsi akan dipindai per unit fungsi untuk memverifikasi semua operasi referensi adalah sah. Proses utama untuk memverifikasi keamanan referensi mencakup langkah-langkah seperti mengeksekusi blok dasar, menghasilkan status pasca, menggabungkan status sebelumnya dan sesudah, dll.
Analisis Kerentanan
Kerentanan muncul dalam fungsi join_ yang mengacu pada modul keamanan. Ketika jumlah panjang parameter fungsi dan panjang variabel lokal lebih besar dari 256, penggunaan tipe u8 untuk merepresentasikan variabel lokal dapat menyebabkan overflow integer.
Meskipun Move memiliki proses untuk memverifikasi jumlah locals, modul check bounds hanya memverifikasi locals dan tidak termasuk panjang parameter. Sepertinya pengembang menyadari perlunya memeriksa jumlah parameter dan nilai lokal, tetapi kode hanya memverifikasi jumlah variabel lokal.
Dari overflow integer ke serangan DoS
Dengan memanfaatkan kerentanan integer overflow ini, penyerang dapat membuat blok kode loop yang mengubah status blok. Ketika fungsi execute_block dijalankan lagi, jika indeks yang perlu diakses oleh instruksi tidak ada dalam peta locals AbstractState yang baru, akan menyebabkan serangan DoS.
Dalam modul reference safety, opcode seperti MoveLoc/CopyLoc/FreeRef dapat memicu situasi ini. Misalnya, dalam fungsi copy_loc, jika LocalIndex tidak ada, maka akan menyebabkan panic, yang selanjutnya menyebabkan seluruh node crash.
Reproduksi Kerentanan
Anda dapat mereproduksi kerentanan ini di git dengan kode PoC berikut:
gerakkan public fun test(a: u64, b: u64, c: u64, d: u64) { let x = 0; loop { jika (x == 1) { istirahat }; x = x + 1; } }
Langkah-langkah untuk memicu DoS adalah sebagai berikut:
Pertama kali mengeksekusi fungsi execute_block, mengatur parameters dan locals keduanya menjadi SignatureIndex(0), yang mengakibatkan num_locals menjadi 264. Setelah menjalankan fungsi join_, panjang map locals baru menjadi 8.
Saat fungsi execute_block dieksekusi untuk kedua kalinya, instruksi pertama dari kode move yang dieksekusi adalah copyloc(57). Karena pada saat ini locals hanya memiliki panjang 8, offset 57 tidak ada, yang menyebabkan fungsi get(57).unwrap() mengembalikan None, yang akhirnya menyebabkan panic.
Ringkasan
Kerentanan ini menunjukkan bahwa tidak ada kode yang sepenuhnya aman. Meskipun bahasa Move melakukan pemeriksaan statis sebelum eksekusi kode, masih mungkin untuk dilalui oleh kerentanan overflow. Ini sekali lagi menekankan pentingnya audit kode.
Untuk bahasa Move, kami menyarankan untuk menambahkan lebih banyak kode pemeriksaan saat runtime untuk mencegah situasi yang tidak diinginkan. Saat ini, Move terutama melakukan pemeriksaan keamanan di tahap verifikasi, tetapi begitu verifikasi dilewati, kurangnya penguatan keamanan yang memadai di tahap eksekusi dapat menyebabkan masalah yang lebih serius.
Sebagai pemimpin penelitian keamanan bahasa Move, kami akan terus mendalami masalah keamanan Move dan membagikan lebih banyak temuan di masa mendatang.