Analisis Kerentanan Compiler Solidity dan Strategi Penanganannya

Compiler adalah salah satu komponen dasar dari sistem komputer modern. Ini adalah program komputer, dengan fungsi utama untuk mengubah kode sumber bahasa pemrograman tingkat tinggi yang mudah dipahami dan ditulis oleh manusia menjadi kode instruksi yang dapat dieksekusi oleh CPU tingkat rendah atau mesin virtual byte.

Sebagian besar pengembang dan petugas keamanan biasanya lebih memperhatikan keamanan kode aplikasi program, tetapi mungkin mengabaikan keamanan compiler itu sendiri. Faktanya, compiler sebagai program komputer juga memiliki celah keamanan, dan celah ini dalam keadaan tertentu dapat membawa risiko keamanan yang serius. Misalnya, saat browser mengkompilasi dan mem-parsing kode frontend Javascript, mungkin terjadi serangan yang memanfaatkan celah pada mesin parsing Javascript, yang memungkinkan penyerang untuk melakukan eksekusi kode jarak jauh saat pengguna mengakses halaman web berbahaya, akhirnya mengontrol browser korban bahkan sistem operasinya.

Kompiler Solidity juga tidak terkecuali, terdapat kerentanan keamanan di beberapa versi yang berbeda.

Kerentanan Kompiler Solidity

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

Diperlukan untuk membedakan antara kerentanan compiler Solidity dan kerentanan EVM itu sendiri. Kerentanan EVM mengacu pada masalah 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 kerentanan keamanan, akan mempengaruhi seluruh jaringan Ethereum, dan dapat menyebabkan penolakan layanan seluruh jaringan (DoS) bahkan menyebabkan seluruh rantai sepenuhnya diambil alih oleh penyerang. Namun, karena desain EVM sendiri relatif sederhana, dan kode inti tidak sering diperbarui, kemungkinan munculnya masalah di atas relatif rendah.

Vulnerabilitas compiler Solidity adalah masalah yang muncul ketika compiler mengubah Solidity menjadi kode EVM. Berbeda dengan skenario di mana browser mengkompilasi dan menjalankan Javascript di komputer klien pengguna, proses kompilasi Solidity hanya dilakukan di komputer pengembang kontrak pintar, dan tidak dijalankan di Ethereum. Oleh karena itu, vulnerabilitas compiler Solidity tidak akan langsung mempengaruhi jaringan Ethereum itu sendiri.

Salah satu bahaya utama dari kerentanan compiler Solidity adalah bahwa ini dapat menyebabkan kode EVM yang dihasilkan tidak sesuai dengan harapan pengembang kontrak pintar. Karena kontrak pintar di Ethereum biasanya melibatkan aset cryptocurrency pengguna, setiap bug kontrak pintar yang disebabkan oleh compiler dapat menyebabkan kerugian aset pengguna dan menghasilkan konsekuensi 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 kerentanan pada compiler Solidity, hanya dengan melakukan audit logika kode sumber kontrak sangat sulit. Diperlukan analisis bersama antara versi compiler tertentu dan pola kode tertentu untuk menentukan apakah kontrak pintar terpengaruh oleh kerentanan compiler.

Contoh Kerentanan Kompiler Solidity

Berikut adalah beberapa contoh nyata dari kerentanan kompilator Solidity, menunjukkan bentuk, penyebab, dan bahaya spesifiknya.

SOL-2016-9 HighOrderByteCleanStorage

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

Pertimbangkan kode berikut:

solidity kontrak C { uint32 a = 0x1234; uint32 b = 0; fungsi f() publik { a += 1; } fungsi run() publik melihat mengembalikan (uint) { return b; } }

Variabel storage b tidak mengalami modifikasi, sehingga fungsi run() seharusnya mengembalikan nilai default 0. Namun, sebenarnya, dalam kode yang dihasilkan oleh versi compiler yang memiliki celah, run() akan mengembalikan 1.

Tanpa memahami kerentanan compiler ini, sulit bagi pengembang biasa untuk menemukan bug yang ada dalam kode di atas melalui pemeriksaan kode yang sederhana. Contoh kode ini cukup sederhana dan mungkin tidak menyebabkan bahaya yang sangat serius. Namun, jika variabel b digunakan untuk verifikasi izin, pencatatan aset, dan tujuan lainnya, ketidaksesuaian dengan yang diharapkan ini dapat menyebabkan konsekuensi yang sangat serius.

Penyebab fenomena anomali ini adalah bahwa EVM menggunakan mesin virtual berbasis tumpukan, di mana setiap elemen dalam tumpukan berukuran 32 byte ( yaitu ukuran variabel uint256 ). Di sisi lain, setiap slot dalam penyimpanan dasar juga berukuran 32 byte. Sementara itu, bahasa Solidity mendukung berbagai tipe data yang lebih kecil dari 32 byte seperti uint32, dan kompiler perlu melakukan operasi pembersihan yang sesuai pada bagian tinggi variabel tersebut ( clean up ) untuk memastikan keakuratan data. Dalam situasi di atas, ketika penjumlahan menyebabkan overflow integer, kompiler tidak dengan benar membersihkan bagian tinggi dari hasil, yang menyebabkan bit 1 pada bagian tinggi tertulis ke dalam penyimpanan, akhirnya menimpa variabel a di belakang variabel b, sehingga nilai variabel b berubah menjadi 1.

SOL-2022-4 InlineAssemblyMemorySideEffects

Vuln ini ada di compiler versi >=0.8.13 <0.8.15. Pertimbangkan kode berikut:

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

Compiler Solidity tidak hanya menerjemahkan bahasa Solidity menjadi kode EVM, tetapi juga melakukan analisis aliran kontrol dan data yang mendalam, serta menerapkan berbagai proses optimasi kompilasi untuk mengurangi ukuran kode yang dihasilkan dan mengoptimalkan konsumsi gas selama proses eksekusi. Operasi optimasi semacam ini sangat umum di compiler berbagai bahasa tingkat tinggi, tetapi karena banyaknya situasi yang perlu dipertimbangkan, sangat mudah untuk muncul bug atau celah keamanan.

Kerentanan dalam kode di atas berasal dari jenis operasi optimasi ini. Pertimbangkan situasi berikut: jika ada kode dalam suatu 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 di kemudian hari.

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

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

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

solidity kontrak C { fungsi f###uint8( calldata a[4] publik murni mengembalikan )string memory( { return string)abi.encode(a(); } }

Dalam kondisi normal, variabel a yang dikembalikan oleh kode di atas seharusnya "aaaa". Namun, dalam versi yang memiliki kerentanan, itu akan mengembalikan string kosong "".

Penyebab kerentanan ini adalah bahwa Solidity melakukan operasi abi.encode pada array tipe calldata dan secara keliru membersihkan beberapa data, yang menyebabkan modifikasi pada data lain yang berdekatan, sehingga menyebabkan ketidakkonsistenan pada data setelah pengkodean dan pengkodean ulang.

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

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

Saran Keamanan

Berdasarkan analisis model ancaman kerentanan compiler Solidity dan penelusuran kerentanan historis, berikut adalah beberapa saran untuk pengembang dan petugas keamanan.

Untuk Pengembang:

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

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

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

Kepada petugas keamanan:

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

• Dalam proses pengembangan internal SDL, mendorong tim pengembang untuk memperbarui versi compiler Solidity, dan dapat mempertimbangkan untuk memperkenalkan pemeriksaan otomatis untuk versi compiler dalam proses CI/CD.

• Namun, tidak perlu panik berlebihan terhadap kerentanan compiler, sebagian besar kerentanan compiler hanya terpicu dalam pola kode tertentu, dan tidak berarti kontrak yang dikompilasi dengan versi compiler yang rentan selalu memiliki risiko keamanan; dampak keamanan yang sebenarnya perlu dievaluasi secara spesifik berdasarkan situasi proyek.

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 versi yang berbeda:

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

Ringkasan

Artikel ini dimulai dengan konsep dasar compiler, memperkenalkan kerentanan compiler Solidity, dan menganalisis risiko keamanan yang mungkin ditimbulkan dalam lingkungan pengembangan Ethereum yang sebenarnya, serta memberikan beberapa saran keamanan praktis bagi pengembang dan personel keamanan.

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