- Topik
76k Popularitas
33k Popularitas
10k Popularitas
4k Popularitas
4k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
13k Popularitas
3k Popularitas
- Sematkan
76k Popularitas
33k Popularitas
10k Popularitas
4k Popularitas
4k Popularitas
29k Popularitas
16k Popularitas
22k Popularitas
13k Popularitas
3k Popularitas
Analisis kerentanan compiler Solidity dan strategi penanganannya
Penjelasan Rincian Kerentanan Compiler Solidity dan Strategi Penanganannya
Kompiler adalah salah satu komponen dasar dari sistem komputer modern. Ini adalah program komputer, fungsi utamanya adalah mengubah kode sumber bahasa pemrograman tingkat tinggi menjadi kode instruksi yang dapat dieksekusi oleh CPU atau mesin virtual di tingkat bawah komputer.
Meskipun sebagian besar pengembang dan petugas keamanan biasanya lebih fokus pada keamanan kode aplikasi, keamanan kompilator itu sendiri juga sangat penting. Sebagai program komputer, kompilator juga dapat memiliki kerentanan keamanan, yang dalam beberapa kasus dapat menimbulkan risiko keamanan yang serius. Misalnya, saat browser mengkompilasi dan mengurai kode frontend JavaScript, kerentanan pada mesin pengurai JavaScript dapat menyebabkan pengguna diserang oleh penyerang saat mengakses halaman web berbahaya, yang akhirnya dapat mengakibatkan kontrol terhadap browser korban bahkan sistem operasi.
Compiler Solidity juga memiliki celah keamanan. Menurut peringatan keamanan dari tim pengembang Solidity, masalah keamanan telah ditemukan di beberapa versi berbeda dari compiler Solidity.
Kerentanan Kompiler Solidity
Fungsi utama dari compiler Solidity adalah mengubah kode kontrak pintar menjadi kode instruksi EVM (Ethereum Virtual Machine) (. Kode instruksi EVM ini dikemas dalam transaksi dan diunggah ke Ethereum, yang akhirnya akan 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 sembarang ke Ethereum, jika ada kerentanan keamanan di EVM, itu akan mempengaruhi seluruh jaringan Ethereum, dan dapat menyebabkan penolakan layanan )DoS( bahkan seluruh blockchain diambil alih oleh penyerang. Namun, desain EVM relatif sederhana, pembaruan kode inti tidak sering terjadi, sehingga kemungkinan terjadinya masalah semacam ini lebih rendah.
Vulnerabilitas compiler Solidity merujuk pada masalah yang muncul ketika compiler mengubah kode Solidity menjadi kode EVM. Berbeda dengan kasus di mana browser mengompilasi dan menjalankan JavaScript di klien pengguna, proses kompilasi Solidity hanya dilakukan di komputer pengembang kontrak pintar, dan tidak dieksekusi 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 dapat menyebabkan kode EVM yang dihasilkan tidak sesuai dengan yang diharapkan oleh pengembang. Karena kontrak pintar di Ethereum sering melibatkan aset cryptocurrency pengguna, setiap bug kontrak yang disebabkan oleh compiler dapat menyebabkan kerugian aset pengguna, dengan konsekuensi yang serius.
Pengembang dan auditor kontrak mungkin lebih fokus pada masalah implementasi logika kode kontrak, serta masalah keamanan di tingkat Solidity seperti reentrancy dan overflow integer. Namun, kerentanan compiler sering kali sulit ditemukan hanya dengan mengaudit sumber kode kontrak. Diperlukan analisis yang menggabungkan versi compiler tertentu dan pola kode tertentu untuk menentukan apakah kontrak pintar dipengaruhi oleh kerentanan compiler.
![Analisis Kerentanan Compiler Solidity dan Tindakan Penanganan])https://img-cdn.gateio.im/webp-social/moments-7d1e882c0b106528437910218bf21f82.webp(
Contoh Kerentanan Kompilator Solidity
Berikut adalah beberapa contoh nyata dari kerentanan compiler Solidity, yang menunjukkan bentuk, penyebab, dan bahaya spesifiknya.
) SOL-2016-9 HighOrderByteCleanStorage
Kerentanan ini ada di versi awal compiler Solidity ###\u003e=0.1.6 \u003c0.4.4(.
Pertimbangkan kode berikut:
soliditas kontrak C { uint32 a = 0x12345678; uint32 b = 0; function f)( public { a = a + 1; } fungsi run)( publik tampilan mengembalikan )uint( { return b; } }
Variabel storage b tidak mengalami modifikasi apapun, sehingga fungsi run)( seharusnya mengembalikan nilai default 0. Namun, dalam kode yang dihasilkan oleh compiler versi rentan, run)( akan mengembalikan 1.
Tanpa memahami kerentanan compiler tersebut, pengembang biasa akan kesulitan untuk menemukan bug ini hanya dengan pemeriksaan kode sederhana. Meskipun contoh ini relatif sederhana dan tidak akan menyebabkan konsekuensi yang sangat serius, jika variabel b digunakan untuk otentikasi, pencatatan aset, dan tujuan lainnya, ketidaksesuaian ini dengan yang diharapkan dapat menyebabkan konsekuensi yang sangat serius.
Penyebab fenomena ini 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 penyimpanan dasar juga berukuran 32 byte. Sementara itu, bahasa Solidity mendukung tipe data yang lebih kecil dari 32 byte seperti uint32, dan kompilator perlu melakukan operasi pembersihan yang tepat pada bit tinggi ketika menangani tipe-tipe ini )clean up( untuk memastikan keakuratan data. Dalam situasi di atas, ketika penjumlahan menghasilkan overflow integer, kompilator tidak secara benar melakukan clean up pada bit tinggi dari hasil, yang menyebabkan bit 1 yang tinggi ditulis ke dalam penyimpanan, akhirnya menimpa variabel a yang berada di belakang variabel b, sehingga nilai variabel b diubah menjadi 1.
) SOL-2022-4 InlineAssemblyMemorySideEffects
Kerentanan ini ada di dalam 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; } }
Kompiler Solidity dalam proses mengubah bahasa Solidity menjadi kode EVM, tidak hanya melakukan terjemahan sederhana, tetapi juga melakukan analisis kontrol aliran dan data yang mendalam, untuk mencapai berbagai optimasi kompilasi, guna mengurangi ukuran kode yang dihasilkan dan mengoptimalkan konsumsi gas selama proses eksekusi. Optimasi semacam ini umum ditemukan di kompiler berbagai bahasa tingkat tinggi, tetapi karena situasi yang perlu dipertimbangkan kompleks, mudah muncul bug atau celah keamanan.
Kerentanan dalam kode di atas berasal dari jenis operasi optimisasi ini. Jika ada kode dalam suatu fungsi yang mengubah data di offset memori 0, tetapi data tersebut tidak digunakan selanjutnya, 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 compiler Solidity yang spesifik, optimasi semacam itu hanya diterapkan pada blok assembly tunggal. Untuk kode PoC di atas, penulisan dan akses ke memori 0 berada di dua blok assembly yang berbeda, sedangkan compiler hanya menganalisis dan mengoptimalkan blok assembly secara terpisah. Karena setelah penulisan memori 0 di blok assembly pertama tidak ada operasi pembacaan, maka instruksi penulisan tersebut dinyatakan redundan dan akan dihapus, sehingga menghasilkan bug. Dalam versi yang rentan, fungsi f)( akan mengembalikan nilai 0, padahal nilai pengembalian yang benar seharusnya adalah 0x42.
) SOL-2022-6 AbiReencodingHeadOverflowWithStaticArrayCleanup
Kerentanan ini mempengaruhi versi compiler >= 0.5.8 < 0.8.16.
Pertimbangkan kode berikut:
soliditas kontrak C { function f###string( calldata a[1] public 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 celah, akan mengembalikan string kosong "".
Penyebab kerentanan ini adalah operasi abi.encode pada array tipe calldata di Solidity yang secara keliru membersihkan beberapa data, mengakibatkan modifikasi pada data lain yang berdekatan, sehingga menyebabkan ketidakcocokan data setelah pengkodean dan pengkodean ulang.
Perlu dicatat bahwa Solidity secara implisit akan melakukan abi.encode pada parameter saat melakukan external call dan emit event, sehingga kemungkinan munculnya kode kerentanan di atas akan lebih tinggi daripada yang diperkirakan.
![Analisis Kerentanan Compiler Solidity dan Tindakan Penanggulangan][0]https://img-cdn.gateio.im/webp-social/moments-c97428f89ed62d5ad8551cdb2ba30867.webp(
Saran Keamanan
Terkait ancaman kerentanan pada compiler Solidity, berikut adalah beberapa saran bagi pengembang dan personel keamanan:
Untuk Pengembang:
Gunakan versi compiler Solidity yang lebih baru. Meskipun versi baru mungkin memperkenalkan masalah keamanan baru, masalah keamanan yang diketahui biasanya lebih sedikit dibandingkan versi yang lebih lama.
Memperbaiki kasus uji unit. Sebagian besar bug di tingkat kompiler dapat menyebabkan hasil eksekusi kode tidak sesuai dengan yang diharapkan. Masalah seperti ini sulit ditemukan melalui tinjauan kode, tetapi mudah terungkap pada tahap pengujian. Meningkatkan cakupan kode dapat meminimalkan masalah semacam ini.
Usahakan untuk menghindari penggunaan inline assembly, serta operasi kompleks seperti encoding/decoding abi untuk array multidimensi dan struktur kompleks. Hindari penggunaan fitur bahasa baru dan fungsi eksperimental secara sembarangan jika tidak ada kebutuhan yang jelas. Sebagian besar kerentanan sejarah terkait dengan operasi seperti inline assembly dan encoder abi. Kompiler lebih mudah mengalami bug saat menangani fitur bahasa yang kompleks. Di sisi lain, pengembang juga mudah terjebak dalam kesalahan penggunaan saat menggunakan fitur baru, yang dapat mengakibatkan masalah keamanan.
Untuk petugas keamanan:
Saat melakukan audit keamanan pada kode Solidity, jangan abaikan risiko keamanan yang mungkin ditimbulkan oleh kompiler. Item pemeriksaan yang sesuai dalam Smart Contract Weakness Classification)SWC( adalah SWC-102: Versi Kompiler yang Usang.
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 bahwa kontrak yang dikompilasi menggunakan versi compiler yang rentan pasti memiliki risiko keamanan. Dampak keamanan yang sebenarnya perlu dievaluasi berdasarkan situasi proyek.
Beberapa sumber daya yang berguna:
![Analisis Kerentanan Compiler Solidity dan Langkah Penanganannya])https://img-cdn.gateio.im/webp-social/moments-84f5083d8748f2aab71fd92671d999a7.webp(
Ringkasan
Artikel ini dimulai dari konsep dasar compiler, memperkenalkan kerentanan compiler Solidity, menganalisis risiko keamanan yang mungkin ditimbulkan dalam lingkungan pengembangan Ethereum yang sebenarnya, dan memberikan beberapa saran keamanan praktis untuk pengembang dan personel keamanan. Dengan memahami dan memperhatikan kerentanan compiler, kita dapat lebih komprehensif dalam memastikan keamanan kontrak pintar.