Uniswap v4 akan segera diluncurkan, mekanisme Hook menyimpan risiko keamanan
Uniswap v4 akan segera diluncurkan, pembaruan kali ini memperkenalkan banyak fungsi baru, termasuk dukungan untuk jumlah kolam likuiditas yang tidak terbatas untuk setiap pasangan perdagangan dan biaya dinamis, desain tunggal, pencatatan kilat, mekanisme Hook, serta dukungan untuk standar token ERC1155. v4 diperkirakan akan diluncurkan setelah pembaruan Ethereum Cancun.
Di antara banyak inovasi, mekanisme Hook menarik perhatian karena potensi kuatnya. Ini memungkinkan eksekusi kode kustom pada titik tertentu dalam siklus hidup kolam likuiditas, yang secara signifikan meningkatkan skalabilitas dan fleksibilitas kolam.
Namun, mekanisme Hook juga bisa menjadi pedang bermata dua. Meskipun kuat dan fleksibel, penggunaan Hook yang aman juga menghadapi tantangan. Kompleksitas Hook secara tak terhindarkan membawa vektor serangan potensial baru. Oleh karena itu, memperkenalkan secara sistematis masalah keamanan dan risiko potensial terkait mekanisme Hook sangat penting, yang akan membantu membangun Hook Uniswap v4 yang lebih aman.
Artikel ini akan memperkenalkan konsep terkait mekanisme Hook di Uniswap v4 dan memberikan gambaran tentang risiko keamanan yang ada.
Mekanisme Uniswap V4
Sebelum membahas lebih dalam, kita perlu memiliki pemahaman dasar tentang mekanisme Uniswap v4. Menurut pengumuman resmi dan buku putih, Hook, arsitektur tunggal, dan pembukuan kilat adalah tiga fungsi penting untuk mewujudkan kolam likuiditas yang disesuaikan dan routing efisien di berbagai kolam.
Hook
Hook merujuk pada kontrak yang berjalan di berbagai tahap siklus hidup kolam dana likuiditas. Tim Uniswap berharap dengan memperkenalkan Hook, siapa pun dapat membuat keputusan trade-off. Cara ini dapat mewujudkan dukungan asli untuk biaya dinamis, menambahkan limit order on-chain, atau melalui pembuat pasar berbobot waktu (TWAMM) untuk mendiversifikasi pesanan besar.
Saat ini ada delapan callback Hook, dibagi menjadi empat grup ( setiap grup berisi sepasang callback ):
sebelumInisialisasi/setelahInisialisasi
sebelumUbahPosisi/setelahUbahPosisi
sebelumTukar/setelahTukar
sebelumDonasi/setelahDonasi
Singleton, pencatatan kilat, dan mekanisme kunci
Arsitektur singleton dan pembukuan kilat bertujuan untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak singleton baru, di mana semua kolam likuiditas disimpan dalam kontrak pintar yang sama. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.
Versi v4 memperkenalkan akuntansi kilat dan mekanisme penguncian. Cara kerja mekanisme penguncian adalah sebagai berikut:
Kontrak locker meminta lock di PoolManager.
PoolManager menambahkan alamat kontrak locker tersebut ke dalam antrean lockData, dan memanggil callback lockAcquired-nya.
Kontrak locker menjalankan logikanya dalam callback. Selama proses eksekusi, interaksi kontrak locker dengan kolam dapat menyebabkan peningkatan mata uang yang tidak nol. Namun, pada akhir eksekusi, semua peningkatan harus diselesaikan menjadi nol. Selain itu, jika antrean lockData tidak kosong, hanya kontrak locker terakhir yang dapat melakukan operasi.
PoolManager memeriksa status antrean lockData dan peningkatan mata uang. Setelah verifikasi, PoolManager akan menghapus kontrak locker tersebut.
Singkatnya, mekanisme penguncian mencegah akses bersamaan dan memastikan bahwa semua transaksi dapat diselesaikan. Kontrak locker mengajukan lock secara berurutan, kemudian mengeksekusi transaksi melalui callback lockAcquired. Setiap kali operasi pool dilakukan, callback Hook yang sesuai akan dipicu. Akhirnya, PoolManager akan memeriksa status.
Metode ini berarti bahwa penyesuaian operasional adalah pada saldo bersih internal ( yaitu delta ), bukan melakukan transfer instan. Setiap modifikasi akan dicatat dalam saldo internal kolam, sedangkan transfer yang sebenarnya dilakukan pada akhir operasi ( yaitu lock ). Proses ini menjamin tidak ada token yang belum diselesaikan, sehingga menjaga integritas dana.
Karena adanya mekanisme penguncian, semua akun eksternal (EOA) tidak dapat berinteraksi langsung dengan PoolManager. Sebaliknya, setiap interaksi harus dilakukan melalui suatu kontrak. Kontrak tersebut bertindak sebagai pengunci perantara, yang perlu meminta kunci sebelum melakukan operasi kolam apa pun.
Terdapat dua skenario interaksi kontrak utama:
kontrak locker berasal dari repositori kode resmi, atau dikerahkan oleh pengguna. Dalam hal ini, kita dapat menganggap interaksi dilakukan melalui router.
kontrak locker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikendalikan oleh entitas pihak ketiga. Untuk situasi ini, kita dapat melihat interaksi sebagai melalui Hook. Dalam hal ini, Hook berfungsi sebagai kontrak locker dan juga bertanggung jawab untuk menangani callback.
Model Ancaman
Sebelum membahas masalah keamanan yang relevan, kita perlu menentukan model ancaman. Dua situasi utama yang perlu dipertimbangkan adalah:
Model ancaman I: Hook itu sendiri bersifat baik, tetapi terdapat celah.
Model Ancaman II: Hook itu sendiri adalah jahat.
Dalam bagian berikut, kami akan membahas potensi masalah keamanan berdasarkan kedua model ancaman ini.
Masalah keamanan dalam model ancaman I
Model ancaman I berfokus pada kerentanan yang terkait dengan Hook itu sendiri. Model ancaman ini mengasumsikan bahwa pengembang dan Hook mereka tidak berniat jahat. Namun, kerentanan yang sudah diketahui dalam kontrak pintar juga dapat muncul dalam Hook.
Kami memilih untuk fokus pada potensi kerentanan yang unik untuk versi v4. Dalam Uniswap v4, Hook adalah kontrak pintar yang dapat menjalankan logika kustom sebelum atau setelah operasi inti pada pool (, termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan ). Meskipun Hook diperkirakan akan menerapkan antarmuka standar, ia juga memungkinkan untuk menyertakan logika kustom. Oleh karena itu, cakupan diskusi kami akan dibatasi pada logika yang melibatkan antarmuka Hook standar. Kemudian, kami akan mencoba mencari sumber kerentanan yang mungkin, misalnya, bagaimana Hook dapat menyalahgunakan fungsi-fungsi Hook standar ini.
Secara khusus, kita akan fokus pada dua jenis Hook berikut:
Jenis hook pertama, menyimpan dana pengguna. Dalam kasus ini, penyerang mungkin akan menyerang hook ini untuk mentransfer dana, menyebabkan kerugian aset.
Jenis hook kedua, menyimpan data status kunci yang bergantung pada pengguna atau protokol lainnya. Dalam kasus ini, penyerang mungkin mencoba untuk mengubah status kunci. Ketika pengguna atau protokol lain menggunakan status yang salah, itu dapat membawa risiko potensial.
Setelah melakukan penelitian mendalam terhadap repositori Awesome Uniswap v4 Hooks, kami menemukan beberapa kerentanan serius. Kerentanan ini terutama berasal dari interaksi risiko antara hook, PoolManager, dan pihak ketiga eksternal, yang dapat dibagi menjadi dua kategori utama: masalah kontrol akses dan masalah validasi input.
Secara keseluruhan, kami menemukan 22 proyek terkait ( mengecualikan proyek yang tidak terkait dengan Uniswap v4 ). Dari proyek-proyek ini, kami percaya ada 8 (36%) proyek yang memiliki kerentanan. Dari 8 proyek yang memiliki kerentanan ini, 6 memiliki masalah kontrol akses, dan 2 rentan terhadap panggilan eksternal yang tidak tepercaya.
Masalah kontrol akses
Dalam diskusi bagian ini, kami terutama fokus pada masalah yang mungkin ditimbulkan oleh fungsi callback dalam v4, termasuk 8 hook callback dan lock callback. Fungsi-fungsi ini seharusnya hanya dapat dipanggil oleh PoolManager, tidak boleh dipanggil oleh alamat lain ( termasuk EOA dan kontrak ). Misalnya, dalam kasus di mana hadiah didistribusikan oleh kunci pool dana, jika fungsi yang sesuai dapat dipanggil oleh akun mana pun, maka hadiah tersebut mungkin akan diterima secara salah.
Oleh karena itu, untuk hook, sangat penting untuk membangun mekanisme kontrol akses yang kuat, terutama karena mereka dapat dipanggil oleh pihak lain selain kolam itu sendiri. Dengan mengelola izin akses secara ketat, kolam likuiditas dapat secara signifikan mengurangi risiko interaksi yang tidak sah atau berbahaya dengan hook.
Masalah verifikasi input
Di Uniswap v4, karena ada mekanisme kunci, pengguna harus mendapatkan satu lock melalui kontrak sebelum melakukan operasi kolam dana apa pun. Ini memastikan bahwa kontrak yang berpartisipasi dalam interaksi saat ini adalah kontrak locker terbaru.
Namun, masih ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak tepercaya yang disebabkan oleh validasi input yang tidak tepat dalam beberapa implementasi Hook yang rentan:
Pertama, hook tidak memverifikasi kolam dana yang ingin diinteraksi oleh pengguna. Ini bisa menjadi kolam dana jahat yang mengandung token palsu dan menjalankan logika berbahaya.
Kedua, beberapa fungsi hook kunci memungkinkan pemanggilan eksternal yang arbitrer.
Panggilan eksternal yang tidak tepercaya sangat berbahaya, karena dapat menyebabkan berbagai jenis serangan, termasuk serangan reentrancy yang kita kenal.
Untuk menyerang hook yang rentan ini, penyerang dapat mendaftarkan kolam dana jahat untuk token palsu mereka sendiri, lalu memanggil hook untuk mengeksekusi operasi di kolam dana. Saat berinteraksi dengan kolam dana, logika token jahat mengambil alih aliran kontrol untuk melakukan perilaku buruk.
Langkah pencegahan terhadap model ancaman I
Untuk menghindari masalah keamanan terkait hook, sangat penting untuk melakukan kontrol akses yang diperlukan terhadap fungsi eksternal/publik yang sensitif dengan tepat, serta melakukan validasi terhadap parameter input untuk memverifikasi interaksi. Selain itu, perlindungan terhadap reentrancy dapat membantu memastikan bahwa hook tidak dieksekusi ulang dalam alur logika standar. Dengan menerapkan langkah-langkah perlindungan keamanan yang tepat, dana dapat mengurangi risiko yang terkait dengan ancaman semacam itu.
Masalah keamanan dalam model ancaman II
Dalam model ancaman ini, kami berasumsi bahwa pengembang dan hook mereka bersifat jahat. Mengingat jangkauan yang luas, kami hanya fokus pada masalah keamanan yang terkait dengan versi v4. Oleh karena itu, kuncinya adalah apakah hook yang diberikan dapat menangani transfer atau otorisasi aset kripto pengguna.
Karena metode akses hook menentukan izin yang mungkin diberikan kepada hook, kami membagi hook menjadi dua kategori:
Hook Terkelola ( Managed Hooks ): hook bukan titik masuk. Pengguna harus berinteraksi dengan hook melalui router ( yang mungkin disediakan oleh Uniswap ).
Hook Mandiri ( Standalone Hooks ): hook adalah titik masuk, memungkinkan pengguna untuk berinteraksi langsung.
Hook yang Dikelola
Dalam kasus ini, aset kripto pengguna ( mencakup token asli dan token lainnya ) yang ditransfer atau diberikan kuasa kepada router. Karena PoolManager melakukan pemeriksaan saldo, hook jahat tidak mudah untuk mencuri aset tersebut secara langsung. Namun, masih ada potensi celah serangan. Misalnya, mekanisme manajemen biaya versi v4 dapat dimanipulasi oleh penyerang melalui hook.
Hook Tipe Mandiri
Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih rumit. Dalam kasus ini, karena pengguna dapat berinteraksi langsung dengan hook, hook memperoleh lebih banyak kekuatan. Secara teoritis, hook dapat melakukan operasi apa pun yang diinginkan melalui interaksi ini.
Dalam versi v4, verifikasi logika kode sangat penting. Masalah utama adalah apakah logika kode dapat dimanipulasi. Jika hook dapat ditingkatkan, ini berarti hook yang tampaknya aman dapat menjadi berbahaya setelah peningkatan, sehingga menimbulkan risiko yang signifikan. Risiko ini termasuk:
Proxy yang dapat ditingkatkan ( dapat diserang langsung );
Memiliki logika penghancuran diri. Dapat diserang dalam kasus pemanggilan bersama selfdestruct dan create2.
Tindakan pencegahan terhadap model ancaman II
Poin yang sangat penting adalah mengevaluasi apakah hook tersebut bersifat jahat. Secara khusus, untuk hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sementara untuk hook independen, fokus utama adalah apakah mereka dapat diperbarui.
Kesimpulan
Artikel ini memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook dari Uniswap v4, mengajukan dua model ancaman dan menguraikan risiko keamanan yang relevan.
Dalam artikel selanjutnya, kami akan melakukan analisis mendalam tentang masalah keamanan di bawah setiap model ancaman.
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Mekanisme Hook Uniswap v4 memiliki risiko keamanan, pakar mengingatkan untuk berhati-hati dalam penggunaannya.
Uniswap v4 akan segera diluncurkan, mekanisme Hook menyimpan risiko keamanan
Uniswap v4 akan segera diluncurkan, pembaruan kali ini memperkenalkan banyak fungsi baru, termasuk dukungan untuk jumlah kolam likuiditas yang tidak terbatas untuk setiap pasangan perdagangan dan biaya dinamis, desain tunggal, pencatatan kilat, mekanisme Hook, serta dukungan untuk standar token ERC1155. v4 diperkirakan akan diluncurkan setelah pembaruan Ethereum Cancun.
Di antara banyak inovasi, mekanisme Hook menarik perhatian karena potensi kuatnya. Ini memungkinkan eksekusi kode kustom pada titik tertentu dalam siklus hidup kolam likuiditas, yang secara signifikan meningkatkan skalabilitas dan fleksibilitas kolam.
Namun, mekanisme Hook juga bisa menjadi pedang bermata dua. Meskipun kuat dan fleksibel, penggunaan Hook yang aman juga menghadapi tantangan. Kompleksitas Hook secara tak terhindarkan membawa vektor serangan potensial baru. Oleh karena itu, memperkenalkan secara sistematis masalah keamanan dan risiko potensial terkait mekanisme Hook sangat penting, yang akan membantu membangun Hook Uniswap v4 yang lebih aman.
Artikel ini akan memperkenalkan konsep terkait mekanisme Hook di Uniswap v4 dan memberikan gambaran tentang risiko keamanan yang ada.
Mekanisme Uniswap V4
Sebelum membahas lebih dalam, kita perlu memiliki pemahaman dasar tentang mekanisme Uniswap v4. Menurut pengumuman resmi dan buku putih, Hook, arsitektur tunggal, dan pembukuan kilat adalah tiga fungsi penting untuk mewujudkan kolam likuiditas yang disesuaikan dan routing efisien di berbagai kolam.
Hook
Hook merujuk pada kontrak yang berjalan di berbagai tahap siklus hidup kolam dana likuiditas. Tim Uniswap berharap dengan memperkenalkan Hook, siapa pun dapat membuat keputusan trade-off. Cara ini dapat mewujudkan dukungan asli untuk biaya dinamis, menambahkan limit order on-chain, atau melalui pembuat pasar berbobot waktu (TWAMM) untuk mendiversifikasi pesanan besar.
Saat ini ada delapan callback Hook, dibagi menjadi empat grup ( setiap grup berisi sepasang callback ):
Singleton, pencatatan kilat, dan mekanisme kunci
Arsitektur singleton dan pembukuan kilat bertujuan untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak singleton baru, di mana semua kolam likuiditas disimpan dalam kontrak pintar yang sama. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.
Versi v4 memperkenalkan akuntansi kilat dan mekanisme penguncian. Cara kerja mekanisme penguncian adalah sebagai berikut:
Kontrak locker meminta lock di PoolManager.
PoolManager menambahkan alamat kontrak locker tersebut ke dalam antrean lockData, dan memanggil callback lockAcquired-nya.
Kontrak locker menjalankan logikanya dalam callback. Selama proses eksekusi, interaksi kontrak locker dengan kolam dapat menyebabkan peningkatan mata uang yang tidak nol. Namun, pada akhir eksekusi, semua peningkatan harus diselesaikan menjadi nol. Selain itu, jika antrean lockData tidak kosong, hanya kontrak locker terakhir yang dapat melakukan operasi.
PoolManager memeriksa status antrean lockData dan peningkatan mata uang. Setelah verifikasi, PoolManager akan menghapus kontrak locker tersebut.
Singkatnya, mekanisme penguncian mencegah akses bersamaan dan memastikan bahwa semua transaksi dapat diselesaikan. Kontrak locker mengajukan lock secara berurutan, kemudian mengeksekusi transaksi melalui callback lockAcquired. Setiap kali operasi pool dilakukan, callback Hook yang sesuai akan dipicu. Akhirnya, PoolManager akan memeriksa status.
Metode ini berarti bahwa penyesuaian operasional adalah pada saldo bersih internal ( yaitu delta ), bukan melakukan transfer instan. Setiap modifikasi akan dicatat dalam saldo internal kolam, sedangkan transfer yang sebenarnya dilakukan pada akhir operasi ( yaitu lock ). Proses ini menjamin tidak ada token yang belum diselesaikan, sehingga menjaga integritas dana.
Karena adanya mekanisme penguncian, semua akun eksternal (EOA) tidak dapat berinteraksi langsung dengan PoolManager. Sebaliknya, setiap interaksi harus dilakukan melalui suatu kontrak. Kontrak tersebut bertindak sebagai pengunci perantara, yang perlu meminta kunci sebelum melakukan operasi kolam apa pun.
Terdapat dua skenario interaksi kontrak utama:
kontrak locker berasal dari repositori kode resmi, atau dikerahkan oleh pengguna. Dalam hal ini, kita dapat menganggap interaksi dilakukan melalui router.
kontrak locker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikendalikan oleh entitas pihak ketiga. Untuk situasi ini, kita dapat melihat interaksi sebagai melalui Hook. Dalam hal ini, Hook berfungsi sebagai kontrak locker dan juga bertanggung jawab untuk menangani callback.
Model Ancaman
Sebelum membahas masalah keamanan yang relevan, kita perlu menentukan model ancaman. Dua situasi utama yang perlu dipertimbangkan adalah:
Model ancaman I: Hook itu sendiri bersifat baik, tetapi terdapat celah.
Model Ancaman II: Hook itu sendiri adalah jahat.
Dalam bagian berikut, kami akan membahas potensi masalah keamanan berdasarkan kedua model ancaman ini.
Masalah keamanan dalam model ancaman I
Model ancaman I berfokus pada kerentanan yang terkait dengan Hook itu sendiri. Model ancaman ini mengasumsikan bahwa pengembang dan Hook mereka tidak berniat jahat. Namun, kerentanan yang sudah diketahui dalam kontrak pintar juga dapat muncul dalam Hook.
Kami memilih untuk fokus pada potensi kerentanan yang unik untuk versi v4. Dalam Uniswap v4, Hook adalah kontrak pintar yang dapat menjalankan logika kustom sebelum atau setelah operasi inti pada pool (, termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan ). Meskipun Hook diperkirakan akan menerapkan antarmuka standar, ia juga memungkinkan untuk menyertakan logika kustom. Oleh karena itu, cakupan diskusi kami akan dibatasi pada logika yang melibatkan antarmuka Hook standar. Kemudian, kami akan mencoba mencari sumber kerentanan yang mungkin, misalnya, bagaimana Hook dapat menyalahgunakan fungsi-fungsi Hook standar ini.
Secara khusus, kita akan fokus pada dua jenis Hook berikut:
Jenis hook pertama, menyimpan dana pengguna. Dalam kasus ini, penyerang mungkin akan menyerang hook ini untuk mentransfer dana, menyebabkan kerugian aset.
Jenis hook kedua, menyimpan data status kunci yang bergantung pada pengguna atau protokol lainnya. Dalam kasus ini, penyerang mungkin mencoba untuk mengubah status kunci. Ketika pengguna atau protokol lain menggunakan status yang salah, itu dapat membawa risiko potensial.
Setelah melakukan penelitian mendalam terhadap repositori Awesome Uniswap v4 Hooks, kami menemukan beberapa kerentanan serius. Kerentanan ini terutama berasal dari interaksi risiko antara hook, PoolManager, dan pihak ketiga eksternal, yang dapat dibagi menjadi dua kategori utama: masalah kontrol akses dan masalah validasi input.
Secara keseluruhan, kami menemukan 22 proyek terkait ( mengecualikan proyek yang tidak terkait dengan Uniswap v4 ). Dari proyek-proyek ini, kami percaya ada 8 (36%) proyek yang memiliki kerentanan. Dari 8 proyek yang memiliki kerentanan ini, 6 memiliki masalah kontrol akses, dan 2 rentan terhadap panggilan eksternal yang tidak tepercaya.
Masalah kontrol akses
Dalam diskusi bagian ini, kami terutama fokus pada masalah yang mungkin ditimbulkan oleh fungsi callback dalam v4, termasuk 8 hook callback dan lock callback. Fungsi-fungsi ini seharusnya hanya dapat dipanggil oleh PoolManager, tidak boleh dipanggil oleh alamat lain ( termasuk EOA dan kontrak ). Misalnya, dalam kasus di mana hadiah didistribusikan oleh kunci pool dana, jika fungsi yang sesuai dapat dipanggil oleh akun mana pun, maka hadiah tersebut mungkin akan diterima secara salah.
Oleh karena itu, untuk hook, sangat penting untuk membangun mekanisme kontrol akses yang kuat, terutama karena mereka dapat dipanggil oleh pihak lain selain kolam itu sendiri. Dengan mengelola izin akses secara ketat, kolam likuiditas dapat secara signifikan mengurangi risiko interaksi yang tidak sah atau berbahaya dengan hook.
Masalah verifikasi input
Di Uniswap v4, karena ada mekanisme kunci, pengguna harus mendapatkan satu lock melalui kontrak sebelum melakukan operasi kolam dana apa pun. Ini memastikan bahwa kontrak yang berpartisipasi dalam interaksi saat ini adalah kontrak locker terbaru.
Namun, masih ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak tepercaya yang disebabkan oleh validasi input yang tidak tepat dalam beberapa implementasi Hook yang rentan:
Pertama, hook tidak memverifikasi kolam dana yang ingin diinteraksi oleh pengguna. Ini bisa menjadi kolam dana jahat yang mengandung token palsu dan menjalankan logika berbahaya.
Kedua, beberapa fungsi hook kunci memungkinkan pemanggilan eksternal yang arbitrer.
Panggilan eksternal yang tidak tepercaya sangat berbahaya, karena dapat menyebabkan berbagai jenis serangan, termasuk serangan reentrancy yang kita kenal.
Untuk menyerang hook yang rentan ini, penyerang dapat mendaftarkan kolam dana jahat untuk token palsu mereka sendiri, lalu memanggil hook untuk mengeksekusi operasi di kolam dana. Saat berinteraksi dengan kolam dana, logika token jahat mengambil alih aliran kontrol untuk melakukan perilaku buruk.
Langkah pencegahan terhadap model ancaman I
Untuk menghindari masalah keamanan terkait hook, sangat penting untuk melakukan kontrol akses yang diperlukan terhadap fungsi eksternal/publik yang sensitif dengan tepat, serta melakukan validasi terhadap parameter input untuk memverifikasi interaksi. Selain itu, perlindungan terhadap reentrancy dapat membantu memastikan bahwa hook tidak dieksekusi ulang dalam alur logika standar. Dengan menerapkan langkah-langkah perlindungan keamanan yang tepat, dana dapat mengurangi risiko yang terkait dengan ancaman semacam itu.
Masalah keamanan dalam model ancaman II
Dalam model ancaman ini, kami berasumsi bahwa pengembang dan hook mereka bersifat jahat. Mengingat jangkauan yang luas, kami hanya fokus pada masalah keamanan yang terkait dengan versi v4. Oleh karena itu, kuncinya adalah apakah hook yang diberikan dapat menangani transfer atau otorisasi aset kripto pengguna.
Karena metode akses hook menentukan izin yang mungkin diberikan kepada hook, kami membagi hook menjadi dua kategori:
Hook Terkelola ( Managed Hooks ): hook bukan titik masuk. Pengguna harus berinteraksi dengan hook melalui router ( yang mungkin disediakan oleh Uniswap ).
Hook Mandiri ( Standalone Hooks ): hook adalah titik masuk, memungkinkan pengguna untuk berinteraksi langsung.
Hook yang Dikelola
Dalam kasus ini, aset kripto pengguna ( mencakup token asli dan token lainnya ) yang ditransfer atau diberikan kuasa kepada router. Karena PoolManager melakukan pemeriksaan saldo, hook jahat tidak mudah untuk mencuri aset tersebut secara langsung. Namun, masih ada potensi celah serangan. Misalnya, mekanisme manajemen biaya versi v4 dapat dimanipulasi oleh penyerang melalui hook.
Hook Tipe Mandiri
Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih rumit. Dalam kasus ini, karena pengguna dapat berinteraksi langsung dengan hook, hook memperoleh lebih banyak kekuatan. Secara teoritis, hook dapat melakukan operasi apa pun yang diinginkan melalui interaksi ini.
Dalam versi v4, verifikasi logika kode sangat penting. Masalah utama adalah apakah logika kode dapat dimanipulasi. Jika hook dapat ditingkatkan, ini berarti hook yang tampaknya aman dapat menjadi berbahaya setelah peningkatan, sehingga menimbulkan risiko yang signifikan. Risiko ini termasuk:
Proxy yang dapat ditingkatkan ( dapat diserang langsung );
Memiliki logika penghancuran diri. Dapat diserang dalam kasus pemanggilan bersama selfdestruct dan create2.
Tindakan pencegahan terhadap model ancaman II
Poin yang sangat penting adalah mengevaluasi apakah hook tersebut bersifat jahat. Secara khusus, untuk hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sementara untuk hook independen, fokus utama adalah apakah mereka dapat diperbarui.
Kesimpulan
Artikel ini memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook dari Uniswap v4, mengajukan dua model ancaman dan menguraikan risiko keamanan yang relevan.
Dalam artikel selanjutnya, kami akan melakukan analisis mendalam tentang masalah keamanan di bawah setiap model ancaman.