Analisis Kerentanan Compiler Solidity dan Strategi Penanganan

Kompiler adalah salah satu komponen inti dari sistem komputer modern. Ia mengubah bahasa pemrograman tingkat tinggi yang mudah dipahami manusia menjadi instruksi tingkat rendah yang dapat dieksekusi oleh komputer. Meskipun pengembang dan ahli keamanan biasanya fokus pada keamanan kode aplikasi, masalah keamanan kompilernya sendiri juga tidak dapat diabaikan. Kerentanan kompilator dalam beberapa kasus dapat memicu risiko keamanan yang serius.

Sebagai contoh dengan browser, saat menganalisis dan menjalankan kode JavaScript, kerentanan di mesin JavaScript dapat menyebabkan pengguna mengalami serangan eksekusi kode jarak jauh saat mengunjungi halaman web berbahaya, yang pada akhirnya memungkinkan penyerang mengendalikan browser korban bahkan sistem operasi. Selain itu, bug di kompiler C++ juga dapat menyebabkan konsekuensi serius seperti eksekusi kode jarak jauh.

Kompiler Solidity tidak terkecuali, ada kerentanan keamanan di berbagai versi. Fungsi dari kompiler Solidity adalah untuk mengubah kode kontrak pintar menjadi kode instruksi Ethereum Virtual Machine (EVM), yang akhirnya dieksekusi di EVM. Penting untuk dicatat bahwa kerentanan pada kompiler Solidity berbeda dari kerentanan itu sendiri di EVM. Kerentanan EVM merujuk pada masalah keamanan saat mesin virtual mengeksekusi instruksi, yang dapat mempengaruhi seluruh jaringan Ethereum. Sedangkan kerentanan kompiler Solidity adalah masalah yang muncul saat mengubah Solidity menjadi kode EVM.

Salah satu bahaya dari kerentanan compiler Solidity adalah, kode EVM yang dihasilkan mungkin tidak sesuai dengan harapan pengembang. Karena kontrak pintar biasanya melibatkan aset cryptocurrency pengguna, maka bug yang disebabkan oleh compiler dapat mengakibatkan kerugian aset pengguna, yang merupakan konsekuensi yang sangat serius. Pengembang dan auditor sering kali fokus pada implementasi logika kontrak dan kerentanan umum, sedangkan kerentanan compiler perlu dianalisis dengan mempertimbangkan versi tertentu dan pola kode.

Berikut beberapa contoh nyata untuk menunjukkan bentuk, penyebab, dan bahaya dari kerentanan compiler Solidity.

SOL-2016-9 HighOrderByteCleanStorage

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

Pertimbangkan kode berikut:

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

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

Ketidaksesuaian ini sulit ditemukan melalui pemeriksaan kode sederhana. Meskipun kode contoh memiliki dampak terbatas, jika variabel b digunakan untuk verifikasi izin atau akuntansi aset, konsekuensinya akan sangat serius.

Penyebab masalah ini adalah, EVM menggunakan elemen tumpukan berukuran 32 byte, sedangkan setiap slot dalam penyimpanan dasar juga 32 byte. Solidity mendukung tipe data kecil seperti uint32 yang kurang dari 32 byte, dan kompiler perlu membersihkan bit tinggi (clean up) saat menangani tipe ini untuk memastikan keakuratan data. Dalam kasus ini, setelah terjadi overflow penjumlahan, kompiler tidak membersihkan bit tinggi hasil dengan benar, menyebabkan 1 bit yang meluap ditulis ke penyimpanan, menimpa variabel b.

SOL-2022-4 InlineAssemblyMemorySideEffects

Vuln ini ada dalam compiler versi 0.8.13 hingga 0.8.15. Pertimbangkan kode berikut:

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

Kompiler Solidity melakukan analisis aliran kontrol dan data yang mendalam selama proses optimasi untuk mengurangi ukuran kode yang dihasilkan dan mengoptimalkan konsumsi gas. Meskipun optimasi ini umum, namun karena kompleksitas situasinya, mudah muncul bug atau kerentanan keamanan.

Masalah dalam kode di atas berasal dari jenis optimasi ini. Compiler menganggap bahwa jika suatu fungsi mengubah data di offset memori 0, tetapi data tersebut tidak digunakan setelahnya, maka instruksi modifikasi dapat dihapus untuk menghemat gas. Namun, optimasi semacam ini hanya diterapkan dalam satu blok assembly.

Dalam contoh ini, penulisan dan akses memori 0 terjadi di dua blok assembly yang berbeda. Kompiler hanya menganalisis blok assembly secara terpisah, menganggap bahwa penulisan di blok pertama adalah redundan, sehingga menghapusnya, yang menyebabkan bug. Dalam versi yang rentan, fungsi f() akan mengembalikan 0, sedangkan nilai kembalian yang benar seharusnya adalah 0x42.

SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup

Kerentanan ini mempengaruhi versi 0.5.8 hingga 0.8.16 dari kompiler. Pertimbangkan kode berikut:

solidity kontrak C { fungsi f(string[1] calldata a) eksternal murni mengembalikan (string memory) { return abi.decode(abi.encode(a), (string[1]))[0]; } }

Dalam kondisi normal, kode ini seharusnya mengembalikan nilai variabel a "aaaa". Namun, pada versi yang memiliki celah, akan mengembalikan string kosong "".

Masalahnya adalah bahwa saat Solidity melakukan operasi abi.encode pada array tipe calldata, secara keliru membersihkan beberapa data, yang menyebabkan modifikasi pada data yang berdekatan, sehingga menghasilkan ketidakkonsistenan pada data yang di-encode dan di-decode.

Perlu dicatat bahwa Solidity secara implisit melakukan abi.encode pada parameter saat melakukan panggilan eksternal dan mengeluarkan peristiwa, sehingga dampak dari kerentanan ini mungkin lebih besar dari yang diharapkan.

Saran Keamanan

Berdasarkan analisis kerentanan pada compiler Solidity, berikut adalah beberapa saran untuk pengembang dan personel keamanan:

Untuk pengembang:

• Gunakan versi compiler Solidity yang lebih baru. Versi baru mungkin memperkenalkan masalah baru, tetapi masalah keamanan yang diketahui biasanya lebih sedikit.
• Memperbaiki pengujian unit. Kebanyakan bug di tingkat compiler dapat menyebabkan hasil eksekusi tidak sesuai harapan, masalah ini sulit ditemukan melalui tinjauan kode, tetapi mudah terungkap dalam pengujian. Meningkatkan cakupan kode dapat meminimalkan masalah semacam ini.
• Hindari penggunaan assembly inline, dekode ABI yang kompleks, dan operasi lainnya; jangan menggunakan fitur baru dan eksperimental secara sembarangan. Sebagian besar kerentanan historis terkait dengan operasi kompleks ini.

Untuk petugas keamanan:

• Jangan abaikan risiko keamanan yang mungkin diperkenalkan oleh compiler saat melakukan audit. Item pemeriksaan yang sesuai dalam Smart Contract Weakness Classification(SWC) adalah SWC-102: Versi Compiler yang Usang.
• Dalam proses pengembangan SDL, mendorong tim pengembang untuk memperbarui versi compiler, mempertimbangkan untuk memperkenalkan pemeriksaan otomatis versi compiler dalam CI/CD.
• Tidak perlu terlalu khawatir tentang kerentanan compiler. Sebagian besar kerentanan hanya terpicu dalam pola kode tertentu, dan kontrak yang dikompilasi dengan versi yang rentan tidak selalu memiliki risiko, perlu dievaluasi berdasarkan situasi spesifik.

Beberapa sumber daya yang berguna:

• Peringatan keamanan yang dirilis secara berkala oleh tim Solidity
• Daftar bug yang diperbarui secara berkala di repositori resmi Solidity
• Daftar bug compiler di berbagai versi, dapat digunakan untuk pemeriksaan otomatis dalam CI/CD
• Tanda peringatan di sudut kanan atas halaman kode kontrak Etherscan dapat menunjukkan kerentanan keamanan yang ada pada versi compiler saat ini.

Ringkasan

Artikel ini memperkenalkan konsep kerentanan compiler Solidity, menganalisis risiko keamanan yang mungkin ditimbulkan dalam pengembangan Ethereum, dan memberikan saran keamanan praktis untuk pengembang dan personel keamanan. Meskipun kerentanan compiler tidak umum, dampaknya jauh dan layak untuk diperhatikan oleh tim pengembang dan keamanan.