Analisis Kerentanan Compiler Solidity dan Strategi Penanganannya

Kompiler adalah salah satu komponen dasar dari sistem komputer modern. Ini adalah program komputer yang fungsinya adalah mengubah kode sumber bahasa pemrograman tingkat tinggi yang mudah dipahami dan ditulis oleh manusia menjadi kode instruksi yang dapat dieksekusi oleh CPU dasar komputer atau mesin virtual bytecode.

Sebagian besar pengembang dan profesional keamanan biasanya lebih fokus pada keamanan kode aplikasi program, tetapi mungkin mengabaikan keamanan kompilator itu sendiri. Sebenarnya, kompilator sebagai program komputer juga dapat memiliki kerentanan keamanan, dan kerentanan keamanan yang dihasilkan oleh kompilator dalam beberapa kasus dapat menimbulkan risiko keamanan yang serius. Misalnya, selama proses kompilasi dan parsing kode front-end Javascript, kerentanan pada mesin parsing Javascript dapat menyebabkan serangan jarak jauh yang memanfaatkan kerentanan saat pengguna mengakses halaman web berbahaya, yang akhirnya mengontrol browser korban bahkan sistem operasi. Penelitian menunjukkan bahwa bug pada kompilator Clang C++ juga dapat menyebabkan konsekuensi serius seperti eksekusi kode jarak jauh.

Kompiler Solidity juga tidak terkecuali, menurut peringatan keamanan dari tim pengembang Solidity, terdapat beberapa kerentanan keamanan di berbagai versi kompilator Solidity yang berbeda.

Kerentanan Kompiler Solidity

Fungsi kompiler Solidity adalah untuk mengubah kode kontrak pintar yang ditulis oleh pengembang menjadi kode instruksi EVM( mesin virtual Ethereum), yang kemudian dikemas dan diunggah ke Ethereum melalui transaksi, dan akhirnya diparsing dan dieksekusi oleh EVM.

Perlu membedakan antara kerentanan compiler Solidity dan kerentanan yang ada pada EVM itu sendiri. Kerentanan EVM mengacu pada celah keamanan yang muncul saat mesin virtual mengeksekusi instruksi. Karena penyerang dapat mengunggah kode sembarangan ke Ethereum, kode ini pada akhirnya akan dijalankan di setiap program klien P2P Ethereum. Jika EVM memiliki celah keamanan, itu akan mempengaruhi seluruh jaringan Ethereum, yang mungkin menyebabkan penolakan layanan seluruh jaringan (DoS) bahkan dapat mengakibatkan seluruh rantai dikuasai sepenuhnya oleh penyerang. Namun, karena desain EVM itu sendiri relatif sederhana, dan kode inti tidak sering diperbarui, kemungkinan munculnya masalah di atas relatif rendah.

Kerentanan compiler Solidity merujuk pada adanya kelemahan saat compiler mengubah Solidity menjadi kode EVM. Berbeda dengan skenario di mana Javascript dikompilasi dan dijalankan di komputer klien pengguna seperti browser, proses kompilasi Solidity hanya dilakukan di komputer pengembang kontrak pintar dan tidak dijalankan di Ethereum. Oleh karena itu, kerentanan compiler Solidity tidak akan langsung mempengaruhi jaringan Ethereum itu sendiri.

Salah satu bahaya utama dari kerentanan compiler Solidity adalah bahwa ia dapat menyebabkan kode EVM yang dihasilkan tidak sesuai dengan harapan pengembang kontrak pintar. Karena kontrak pintar di Ethereum sering melibatkan aset cryptocurrency pengguna, setiap bug yang disebabkan oleh compiler yang mempengaruhi kontrak pintar dapat menyebabkan kehilangan aset pengguna, yang dapat mengakibatkan konsekuensi yang serius.

Pengembang dan auditor kontrak mungkin akan fokus pada masalah implementasi logika kode kontrak, serta masalah keamanan di tingkat Solidity seperti reentrancy dan overflow integer. Namun, untuk menemukan celah pada compiler Solidity, hanya dengan melakukan audit terhadap logika kode sumber kontrak sangat sulit. Diperlukan analisis bersama antara versi compiler tertentu dan pola kode tertentu untuk menentukan apakah kontrak pintar terpengaruh oleh celah compiler.

Contoh Kerentanan Compiler Solidity

Berikut ini melalui beberapa kasus nyata dari kerentanan compiler Solidity, menunjukkan bentuk spesifik, penyebab, dan bahaya dari kerentanan compiler Solidity.

SOL-2016-9 HighOrderByteCleanStorage

Vulnerabilitas ini ada di versi kompiler Solidity yang lebih awal (>=0.1.6 <0.4.4).

Pertimbangkan kode berikut:

solidity kontrak C { uint32 a = 0x12345678; uint16 b = 0x1234;

fungsi f() publik { a = a + 1; }

fungsi run() publik tampilkan mengembalikan (uint16) { return b; } }

Variabel storage b tidak dimodifikasi, jadi fungsi run() seharusnya mengembalikan nilai default 0. Namun, dalam kode yang dihasilkan oleh versi compiler yang memiliki kerentanan, run() akan mengembalikan 1.

Tanpa memahami kerentanan compiler tersebut, pengembang biasa sulit untuk menemukan bug yang ada dalam kode di atas hanya melalui pemeriksaan kode yang sederhana. Kode di atas hanyalah contoh sederhana, sehingga tidak akan menyebabkan bahaya yang terlalu serius. Namun, jika variabel b digunakan untuk otentikasi, pencatatan aset, dan tujuan lainnya, ketidaksesuaian dengan yang diharapkan ini dapat mengakibatkan konsekuensi yang sangat serius.

Penyebab fenomena abnormal di atas adalah karena EVM menggunakan mesin virtual berbasis tumpukan, di mana setiap elemen dalam tumpukan memiliki ukuran 32 byte ( yaitu ukuran variabel uint256 ). Di sisi lain, setiap slot dalam penyimpanan dasar juga berukuran 32 byte. Namun, bahasa Solidity mendukung berbagai tipe data yang lebih kecil dari 32 byte seperti uint32, dan kompiler perlu melakukan operasi pembersihan yang sesuai pada bit tinggi saat menangani variabel tipe ini (clean up) untuk memastikan keakuratan data. Dalam situasi di atas, ketika penjumlahan menghasilkan overflow bilangan bulat, kompiler tidak melakukan pembersihan yang benar pada bit tinggi hasilnya, mengakibatkan bit 1 di bit tinggi ditulis ke dalam penyimpanan, yang akhirnya menimpa variabel a dan mengubah nilai variabel b menjadi 1.

SOL-2022-4 InlineAssemblyMemorySideEffects

Vuln ini ada di compiler versi >=0.8.13 <0.8.15. Compiler Solidity tidak hanya menerjemahkan bahasa Solidity menjadi kode EVM secara sederhana. Ia juga melakukan analisis kontrol aliran dan data yang mendalam, serta menerapkan berbagai proses optimasi kompilasi untuk mengurangi ukuran kode yang dihasilkan dan mengoptimalkan konsumsi gas selama proses eksekusi. Tindakan optimasi semacam ini umum ditemukan di compiler berbagai bahasa tingkat tinggi, tetapi karena situasi yang harus dipertimbangkan sangat kompleks, juga mudah muncul bug atau kerentanan keamanan.

Pertimbangkan kode berikut:

solidity kontrak C { function f() public pure returns (uint256) { perakitan { mstore(0, 0x42) } uint256 x; perakitan { x := mload(0) } return x; } }

Kerentanan dalam kode di atas berasal dari operasi optimasi kompilasi. Dalam beberapa kasus, jika terdapat kode dalam fungsi yang mengubah data di offset memori 0, tetapi tidak ada tempat lain yang menggunakan data tersebut, maka sebenarnya kode yang mengubah memori 0 dapat langsung dihapus, sehingga menghemat gas, dan tidak mempengaruhi logika program selanjutnya.

Strategi optimasi ini sendiri tidak ada masalah, tetapi dalam implementasi kode compiler Solidity yang spesifik, optimasi semacam itu hanya diterapkan dalam satu blok assembly. Dalam contoh kode di atas, penulisan dan akses ke memori 0 terdapat dalam dua blok assembly yang berbeda, sementara compiler hanya menganalisis dan mengoptimalkan blok assembly yang terpisah. Karena tidak ada operasi pembacaan setelah penulisan memori 0 dalam blok assembly pertama, maka perintah penulisan tersebut dianggap redundan dan akan dihapus, sehingga menghasilkan bug. Dalam versi yang memiliki kerentanan, fungsi f( akan mengembalikan nilai 0, padahal seharusnya kode di atas mengembalikan nilai yang benar 0x42.

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Kerentanan ini mempengaruhi compiler versi >= 0.5.8 < 0.8.16. Pertimbangkan kode berikut:

solidity kontrak C { function f###bytes calldata data( external pure returns )bytes memory( { bytes4) memory a = [bytes4[1]data(]; return abi.encode)a(; } }

Dalam keadaan normal, kode di atas seharusnya mengembalikan variabel a sebagai "aaaa". Namun, dalam versi yang memiliki celah, akan mengembalikan string kosong "".

Penyebab kerentanan ini adalah bahwa Solidity melakukan operasi abi.encode pada array tipe calldata, secara keliru membersihkan beberapa data, yang mengakibatkan perubahan pada data lain yang berdekatan, menyebabkan ketidaksesuaian antara data yang dikodekan dan yang didekodekan.

Perlu dicatat bahwa Solidity secara implisit melakukan abi.encode pada parameter saat melakukan panggilan eksternal dan memancarkan peristiwa, sehingga kemungkinan munculnya kode kerentanan di atas lebih tinggi daripada yang diperkirakan.

Kerentanan ini diadaptasi menjadi salah satu soal blockchain yang terkenal dalam kompetisi keamanan 0ctf 2022, yang menunjukkan dampak kerentanan compiler terhadap kontrak pintar dalam skenario pengembangan yang nyata.

![Analisis dan Tindakan Terhadap Kerentanan Kompiler Solidity])https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(

Saran Keamanan

Untuk ancaman dan respons terhadap kerentanan compiler Solidity, berikut adalah beberapa saran:

Untuk Pengembang:

• Gunakan versi compiler Solidity yang lebih baru. Meskipun versi baru dapat memperkenalkan masalah keamanan baru, masalah keamanan yang diketahui biasanya lebih sedikit dibandingkan dengan versi lama.

• Perbaiki kasus pengujian unit. Sebagian besar bug di tingkat compiler dapat menyebabkan hasil eksekusi kode tidak sesuai dengan yang diharapkan. Masalah semacam ini sulit ditemukan melalui tinjauan kode, tetapi mudah terungkap pada tahap pengujian. Oleh karena itu, meningkatkan cakupan kode dapat meminimalkan masalah semacam ini.

• Usahakan untuk menghindari penggunaan assembly inline, pengkodean dan penguraian abi untuk array multidimensi dan struktur kompleks, serta operasi rumit lainnya. Hindari penggunaan fitur bahasa baru dan fungsi eksperimental tanpa kebutuhan yang jelas. Sebagian besar kerentanan terkait dengan operasi seperti assembly inline dan pengkodean abi. Kompiler lebih mudah mengalami bug saat menangani fitur bahasa yang kompleks. Di sisi lain, pengembang juga dapat mengalami kesalahan saat menggunakan fitur baru, yang dapat menyebabkan masalah keamanan.

Untuk petugas keamanan:

• Dalam melakukan audit keamanan pada kode Solidity, jangan abaikan risiko keamanan yang mungkin diperkenalkan oleh compiler Solidity. Item pemeriksaan yang sesuai dalam Smart Contract Weakness Classification)SWC( adalah SWC-102: Versi Compiler yang Usang.

• Dalam proses pengembangan keamanan internal, mendorong tim pengembang untuk meningkatkan versi compiler Solidity, dan mempertimbangkan untuk memperkenalkan pemeriksaan otomatis terhadap versi compiler dalam proses CI/CD.

• Namun tidak perlu terlalu khawatir tentang kerentanan compiler, sebagian besar kerentanan compiler hanya terpicu dalam pola kode tertentu. Kontrak yang dikompilasi dengan versi compiler yang memiliki kerentanan tidak selalu memiliki risiko keamanan, perlu mengevaluasi dampak keamanan yang sebenarnya berdasarkan situasi proyek yang spesifik.

Beberapa sumber daya praktis:

• Peringatan keamanan yang dirilis secara berkala oleh tim Solidity:

• Daftar bug yang diperbarui secara berkala dari repositori resmi Solidity:

• Daftar bug compiler setiap versi:

• Kontrak di Etherscan - tanda seru segitiga di sudut kanan atas halaman Kode dapat menunjukkan adanya kerentanan keamanan di versi compiler saat ini.

Kesimpulan

Artikel ini memperkenalkan konsep kerentanan compiler Solidity, menganalisis risiko keamanan yang mungkin ditimbulkannya dalam lingkungan pengembangan Ethereum, dan memberikan saran keamanan praktis untuk pengembang dan personel keamanan. Meskipun kerentanan compiler tidak umum, dampaknya bisa sangat serius, sehingga perlu menjadi perhatian bagi pengembang dan personel keamanan.

![Analisis Kerentanan Kompiler Solidity dan Tindakan Penanggulangannya])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(