Analisis Mendalam Kerentanan Keamanan dalam Referensi Bahasa Move

Baru-baru ini, saat kami melakukan penelitian mendalam tentang Aptos Moveevm, kami menemukan sebuah kerentanan overflow integer baru. Proses pemicu kerentanan ini cukup menarik, di bawah ini kami akan melakukan analisis mendalam dan memperkenalkan pengetahuan latar belakang tentang bahasa Move. Melalui penjelasan dalam artikel ini, kami percaya pembaca dapat memiliki pemahaman yang lebih mendalam tentang bahasa Move.

Bahasa Move akan melakukan verifikasi unit kode sebelum mengeksekusi bytecode, dan proses ini dibagi menjadi 4 langkah. Kerentanan yang dibahas dalam artikel ini muncul pada langkah reference_safety.

modul reference_safety mendefinisikan fungsi transfer untuk memvalidasi keamanan referensi dari subjek proses. Ini terutama memeriksa apakah ada referensi yang tergantung, apakah akses referensi yang dapat diubah aman, dan apakah akses referensi penyimpanan global aman, dan masalah lainnya.

Proses verifikasi dimulai dari fungsi entri verifikasi keamanan yang dirujuk, yang akan memanggil analyze_function. Di dalam analyze_function, setiap blok dasar akan divalidasi. Blok dasar adalah urutan kode yang tidak memiliki instruksi cabang kecuali untuk entri dan keluarnya.

Bahasa Move mengidentifikasi blok dasar dengan menjelajahi bytecode, mencari semua instruksi cabang dan urutan instruksi loop. Contoh blok dasar kode Move IR yang khas mungkin terdiri dari 3 blok dasar yang ditentukan oleh instruksi BrTrue, Branch, dan Ret.

Bahasa Move mendukung dua jenis referensi: referensi tidak dapat diubah (&) dan referensi dapat diubah (&mut). Referensi tidak dapat diubah digunakan untuk membaca data, sedangkan referensi dapat diubah digunakan untuk memodifikasi data. Desain ini membantu menjaga keamanan kode dan mengidentifikasi modul pembaca.

Proses utama verifikasi keamanan referensi meliputi: memindai instruksi bytecode dari blok dasar dalam fungsi, dan menentukan apakah semua operasi referensi sah. Proses ini menggunakan struktur AbstractState, yang mencakup grafik pinjaman dan lokal, untuk memastikan keamanan referensi dalam fungsi.

Dalam proses verifikasi, kode blok dasar akan dijalankan, menghasilkan post state, lalu pre state dan post state digabung untuk memperbarui status blok, dan kondisi pasca blok tersebut disebarkan ke blok berikutnya. Proses ini mirip dengan pemikiran Sea of Nodes dalam V8 turbofan.

Kerentanan muncul di fungsi join_. Ketika jumlah panjang parameter dan panjang variabel lokal melebihi 256, karena lokal adalah tipe u8, akan terjadi overflow integer. Meskipun Move memiliki proses verifikasi jumlah locals, tetapi dalam modul check bounds hanya memverifikasi locals, tidak termasuk panjang parameter.

Vulnerability integer overflow ini dapat menyebabkan serangan DoS. Dengan membuat blok kode loop dan memanfaatkan overflow untuk mengubah state blok, dapat membuat peta locals baru berbeda dari sebelumnya. Ketika fungsi execute_block dijalankan lagi, jika indeks yang diperlukan oleh instruksi tidak ada dalam peta locals AbstractState yang baru, maka akan menyebabkan DoS.

Kami menemukan bahwa dalam modul reference safety, opcode MoveLoc/CopyLoc/FreeRef dapat mencapai tujuan ini. Sebagai contoh fungsi copy_loc, jika LocalIndex tidak ada, akan menyebabkan panic, sehingga seluruh node akan crash.

Untuk memverifikasi kerentanan ini, kami menulis sebuah PoC. Blok kode dalam PoC ini berisi instruksi percabangan tanpa syarat, yang setiap kali mengeksekusi instruksi terakhir akan melompat kembali ke instruksi pertama, sehingga blok kode ini akan memanggil fungsi execute_block dan join beberapa kali.

Dengan mengatur parameter yang sesuai, kita dapat mengubah panjang peta locals baru menjadi 8. Pada eksekusi kedua fungsi execute_block, karena panjang locals tidak mencukupi, akan menyebabkan panic.

Kerentanan ini mengingatkan kita bahwa bahkan bahasa yang menekankan keamanan seperti Move pun mungkin memiliki celah. Kami menyarankan para perancang bahasa Move untuk menambah lebih banyak kode pemeriksaan saat runtime untuk mencegah situasi yang tidak diinginkan. Saat ini, bahasa Move terutama melakukan pemeriksaan keamanan pada tahap verifikasi, tetapi ini mungkin belum cukup. Begitu verifikasi dilewati, jika tidak ada penguatan keamanan yang cukup pada tahap runtime, ini dapat menyebabkan masalah yang lebih serius.

Sebagai pemimpin penelitian keamanan bahasa Move, kami akan terus mendalami masalah keamanan Move dan akan membagikan lebih banyak temuan di masa depan.