Analisis Kerentanan Compiler Solidity dan Strategi Penanggulangannya

Kompiler adalah salah satu komponen dasar dari sistem komputer modern. Ini adalah jenis program komputer khusus yang bertanggung jawab 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 bytecode.

Meskipun sebagian besar pengembang dan ahli keamanan biasanya lebih memperhatikan keamanan kode aplikasi, keamanan kompilator itu sendiri juga tidak boleh diabaikan. Sebagai salah satu program komputer, kompilator juga dapat memiliki kerentanan keamanan, yang dalam beberapa kasus dapat menimbulkan risiko keamanan yang serius. Misalnya, saat browser mengkompilasi dan menganalisis kode front-end Javascript, kerentanan di mesin pengurai Javascript dapat memungkinkan penyerang untuk memanfaatkan kerentanan tersebut saat pengguna mengakses situs web berbahaya, yang pada akhirnya mengontrol browser korban bahkan seluruh sistem operasi.

Kompiler Solidity juga tidak terkecuali, ada celah keamanan yang ada di beberapa versi yang berbeda.

Kerentanan Compiler Solidity

Fungsi utama dari compiler Solidity adalah mengubah kode kontrak pintar yang ditulis oleh pengembang menjadi kode instruksi yang dapat dieksekusi oleh Ethereum Virtual Machine (EVM). Kode instruksi EVM ini dikemas dalam transaksi dan diunggah ke jaringan Ethereum, dan akhirnya diparsing dan dieksekusi oleh EVM.

Perlu dicatat bahwa kerentanan compiler Solidity berbeda dengan kerentanan EVM itu sendiri. Kerentanan EVM mengacu pada masalah keamanan yang muncul saat mesin virtual menjalankan instruksi. Karena penyerang dapat mengunggah kode apa pun ke jaringan Ethereum, kode tersebut pada akhirnya akan dijalankan di setiap program klien P2P Ethereum. Jika ada kerentanan keamanan dalam EVM, hal ini dapat mempengaruhi seluruh jaringan Ethereum, menyebabkan penolakan layanan (DoS) bahkan dapat menyebabkan seluruh blockchain dikendalikan oleh penyerang. Namun, karena desain EVM relatif sederhana dan kode inti tidak sering diperbarui, kemungkinan terjadinya masalah semacam itu cukup rendah.

Kerentanan compiler Solidity mengacu pada masalah yang terjadi saat compiler mengubah kode Solidity menjadi kode EVM. Berbeda dengan situasi di mana browser mengkompilasi dan menjalankan Javascript di komputer klien pengguna, proses kompilasi Solidity hanya dilakukan di komputer pengembang kontrak pintar dan tidak dieksekusi di jaringan Ethereum. Oleh karena itu, kerentanan compiler Solidity tidak akan langsung mempengaruhi jaringan Ethereum itu sendiri.

Salah satu bahaya utama dari kerentanan compiler Solidity adalah 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 kontrak pintar yang disebabkan oleh compiler dapat menyebabkan kehilangan aset pengguna, yang mengakibatkan 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, hanya dengan mengaudit logika sumber kode kontrak, sulit untuk menemukan kerentanan pada kompiler Solidity. Diperlukan analisis gabungan antara versi kompiler tertentu dan pola kode tertentu untuk menentukan apakah kontrak pintar terpengaruh oleh kerentanan kompiler.

Contoh Kerentanan Compiler Solidity

Berikut adalah beberapa contoh nyata dari kerentanan compiler Solidity yang menunjukkan bentuk, penyebab, dan bahaya spesifik.

SOL-2016-9 HighOrderByteCleanStorage

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

Pertimbangkan kode berikut:

soliditas kontrak C { uint32 a = 0x1234; uint32 b = 0; fungsi f() publik { a += 1; } function run() public view returns (uint) { return b; } }

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

Pengembang biasa sulit untuk menemukan masalah yang ada dalam kode di atas hanya melalui tinjauan kode yang sederhana. Meskipun contoh ini relatif sederhana dan mungkin tidak menyebabkan konsekuensi yang sangat serius, jika variabel b digunakan untuk tujuan penting seperti verifikasi izin, pencatatan aset, dan sebagainya, situasi yang tidak konsisten dengan harapan ini dapat menyebabkan risiko keamanan yang serius.

Masalah ini berasal dari penggunaan EVM yang menggunakan mesin virtual berbasis stack, di mana setiap elemen dalam stack memiliki ukuran 32 byte (yaitu ukuran variabel uint256). Setiap slot dalam penyimpanan dasar (storage) juga memiliki ukuran 32 byte. Sementara itu, bahasa Solidity mendukung berbagai tipe data yang lebih kecil dari 32 byte seperti uint32, compiler perlu melakukan operasi pembersihan yang tepat pada bit tinggi saat menangani variabel tipe ini untuk memastikan keakuratan data. Dalam situasi di atas, ketika penjumlahan menghasilkan overflow integer, compiler tidak melakukan pembersihan yang benar pada bit tinggi dari hasilnya, yang mengakibatkan bit 1 di bit tinggi setelah overflow ditulis ke dalam storage, akhirnya menimpa variabel a dan mengubah nilai variabel b menjadi 1.

SOL-2022-4 InlineAssemblyMemorySideEffects

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

solidity kontrak C { fungsi f() publik murni mengembalikan (uint) { assembly { mstore(0, 0x42) } uint x; perakitan { x := mload(0) } return x; } }

Kompiler Solidity tidak hanya menerjemahkan bahasa Solidity menjadi kode EVM, tetapi juga melakukan analisis alur kontrol dan data yang mendalam, serta menerapkan berbagai proses optimasi kompilasi untuk mengurangi ukuran kode yang dihasilkan dan mengoptimalkan konsumsi gas selama proses eksekusi. Jenis operasi optimisasi ini umum ditemukan di kompilator berbagai bahasa tingkat tinggi, tetapi karena kompleksitas kasus yang perlu dipertimbangkan, mudah muncul bug atau celah keamanan.

Kekurangan dalam kode di atas berasal dari jenis operasi optimasi ini. Kompiler beranggapan bahwa jika ada kode dalam suatu fungsi yang memodifikasi data di offset memori 0, tetapi tidak ada tempat lain yang menggunakan data tersebut, maka kode yang mengubah memori 0 dapat dihapus langsung, sehingga menghemat gas dan tidak mempengaruhi logika program berikutnya.

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

) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

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

solidity kontrak C { function f###string( calldata a[1] external pure returns )string memory( { return abi.decode)abi.encode(a(, )string([1])); } }

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

Penyebab kerentanan ini adalah bahwa Solidity secara keliru melakukan pembersihan terhadap beberapa data saat melakukan operasi abi.encode pada array tipe calldata, yang mengakibatkan perubahan pada data lain yang berdekatan, menyebabkan ketidakcocokan data setelah pengkodean dan pengkodean ulang.

Perlu dicatat bahwa Solidity secara implisit akan melakukan abi.encode pada parameter saat melakukan panggilan eksternal dan mengeluarkan event, sehingga kemungkinan munculnya kode kerentanan di atas lebih tinggi daripada yang terlihat secara intuitif.

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

Saran Keamanan

Setelah menganalisis model ancaman kerentanan compiler Solidity serta merangkum kerentanan sejarah, kami memberikan saran berikut kepada pengembang dan pihak keamanan.

) Untuk Pengembang:

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

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

3. Usahakan untuk menghindari penggunaan assembly in-line, pengkodean dan dekode ABI untuk array multidimensi dan struktur kompleks, serta operasi kompleks lainnya. Hindarilah penggunaan fitur baru dan fungsi eksperimental tanpa kebutuhan yang jelas demi mengejar keahlian. Berdasarkan analisis kerentanan sejarah, sebagian besar kerentanan terkait dengan operasi seperti assembly in-line dan pengkode ABI. Kompiler lebih mudah mengalami bug saat menangani fitur bahasa yang kompleks. Di sisi lain, pengembang juga rentan terhadap kesalahan penggunaan saat memanfaatkan fitur baru, yang dapat menyebabkan masalah keamanan.

Untuk petugas keamanan:

1. Saat 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 Usang.

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

3. Namun, tidak perlu panik berlebihan terhadap kerentanan compiler, sebagian besar kerentanan compiler hanya dipicu dalam pola kode tertentu, dan tidak semua kontrak yang dikompilasi dengan versi compiler yang rentan pasti memiliki risiko keamanan. Dampak keamanan yang sebenarnya perlu dievaluasi berdasarkan situasi proyek.

Sumber Daya Praktis

• Artikel peringatan keamanan yang dirilis secara berkala oleh tim Solidity
• Daftar bug yang diperbarui secara berkala dari repositori resmi Solidity
• Daftar bug compiler untuk setiap versi. Dapat digunakan untuk memperkenalkan pemeriksaan versi compiler secara otomatis selama proses CI/CD, memberi tahu tentang kerentanan keamanan yang ada di versi saat ini. Code di Etherscan, ikon tanda seru segitiga di sudut kanan atas dapat menunjukkan kerentanan keamanan yang ada pada versi kompiler saat ini.

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

Ringkasan

Artikel ini memulai dari konsep dasar compiler, memperkenalkan kerentanan compiler Solidity, dan menganalisis risiko keamanan yang mungkin ditimbulkan dalam lingkungan pengembangan Ethereum yang sebenarnya. Terakhir, artikel ini memberikan beberapa saran praktis untuk pengembang dan personel keamanan. Dengan memahami kerentanan ini dan mengambil langkah pencegahan yang sesuai, kita dapat lebih baik melindungi keamanan kontrak pintar dan mengurangi risiko kehilangan aset yang potensial.