Dualitas Mekanisme Hook Uniswap v4: Inovasi dan Risiko Potensial yang Bersamaan
Uniswap v4 akan segera diluncurkan, dan kali ini pembaruan ini sangat ambisius. Versi baru ini akan memperkenalkan berbagai fitur 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. Dengan memanfaatkan teknologi penyimpanan transien, Uniswap v4 diperkirakan akan dirilis setelah pembaruan Ethereum Cancun.
Di antara banyak inovasi, mekanisme Hook menarik perhatian karena potensinya yang besar. Mekanisme 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 fungsionalitasnya kuat dan fleksibel, penggunaan Hook yang aman juga menghadapi tantangan yang tidak kecil. Kompleksitas Hook secara tak terhindarkan membawa vektor serangan potensial baru. Oleh karena itu, perlu untuk memperkenalkan secara sistematis masalah keamanan dan risiko potensial yang terkait dengan mekanisme Hook, untuk mendorong perkembangan keamanan komunitas, wawasan ini akan membantu membangun Hook Uniswap v4 yang lebih aman.
Artikel ini akan memperkenalkan konsep terkait mekanisme Hook dalam 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 dapat disesuaikan dan routing yang efisien di berbagai kolam.
1.1 Hook
Hook adalah kontrak yang berjalan pada berbagai tahap siklus hidup kolam dana likuiditas, tim Uniswap berharap dengan memperkenalkan Hook, siapa pun dapat membuat keputusan perdagangan. Cara ini memungkinkan dukungan asli untuk biaya dinamis, menambahkan limit order on-chain, atau menggunakan rata-rata tertimbang waktu untuk melakukan market making (TWAMM) untuk memecah 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
Tim Uniswap menyediakan beberapa contoh ( seperti cara kerja TWAMM Hook ), dan peserta komunitas juga memberikan beberapa kontribusi. Dokumentasi resmi juga menghubungkan ke repositori Awesome Uniswap v4 Hooks, yang mengumpulkan lebih banyak contoh Hook.
1.2 Singleton, pencatatan kilat, dan mekanisme kunci
Arsitektur singleton dan pencatatan kilat bertujuan untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak singleton baru, di mana semua kolam likuiditas disimpan dalam satu kontrak pintar. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.
Versi Uniswap v4 memperkenalkan pencatatan kilat dan mekanisme penguncian. Cara kerja mekanisme penguncian adalah sebagai berikut:
Kontrak locker meminta lock di PoolManager.
PoolManager menambahkan alamat kontrak locker ke antrean lockData dan memanggil callback lockAcquired.
Kontrak locker menjalankan logikanya dalam callback. Selama proses eksekusi, interaksi kontrak locker dengan pool 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 diverifikasi, PoolManager akan menghapus kontrak locker tersebut.
Singkatnya, mekanisme kunci mencegah akses bersamaan dan memastikan semua transaksi dapat diselesaikan. Kontrak locker mengajukan kunci secara berurutan, dan kemudian mengeksekusi transaksi melalui callback lockAcquired. Setiap kali operasi kolam dilakukan, callback Hook yang sesuai akan dipicu. Akhirnya, PoolManager akan memeriksa status.
Metode ini berarti bahwa penyesuaian yang dilakukan adalah pada saldo bersih internal ( yaitu delta ), dan bukan pada pelaksanaan transfer instan. Setiap modifikasi akan dicatat pada saldo internal kolam, sedangkan transfer nyata dilakukan pada akhir operasi ( yaitu lock ). Proses ini menjamin bahwa 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 kontrak. Kontrak ini berfungsi sebagai pengunci perantara, dan sebelum melakukan operasi kolam apapun, permintaan penguncian harus diajukan.
Terdapat dua skenario interaksi kontrak yang utama:
kontrak locker berasal dari repositori kode resmi atau di-deploy oleh pengguna. Situasi ini dapat dianggap sebagai interaksi melalui router.
kontrak locker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikendalikan oleh entitas pihak ketiga. Situasi ini dapat dianggap sebagai interaksi melalui Hook. Pada saat ini, Hook berperan 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 benign, tetapi terdapat kerentanan.
Model ancaman II: Hook itu sendiri adalah jahat.
Selanjutnya akan dibahas masalah keamanan potensial berdasarkan dua model ancaman ini.
2.1 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 di kontrak pintar juga dapat muncul di Hook. Misalnya, jika Hook diimplementasikan sebagai kontrak yang dapat ditingkatkan, maka mungkin akan mengalami masalah terkait yang mirip dengan kerentanan UUPSUpgradeable dari OpenZeppelin.
Mengingat faktor-faktor di atas, kami memilih untuk fokus pada potensi kerentanan yang spesifik untuk versi v4. Di Uniswap v4, Hook adalah kontrak pintar yang dapat menjalankan logika kustom sebelum atau setelah operasi dalam pool inti (, termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan ). Meskipun Hook diperkirakan akan menerapkan antarmuka standar, ia juga memungkinkan untuk menyertakan logika kustom. Oleh karena itu, ruang lingkup diskusi kami akan dibatasi pada logika yang melibatkan antarmuka Hook standar. Kemudian, kami akan mencoba mencari tahu kemungkinan sumber kerentanan, misalnya, bagaimana Hook dapat menyalahgunakan fungsi Hook standar ini.
Secara khusus, kami akan fokus pada dua jenis Hook berikut:
Jenis pertama hook, menyimpan dana pengguna. Dalam kasus ini, penyerang mungkin akan menyerang hook ini untuk memindahkan dana, menyebabkan kerugian aset.
Jenis hook kedua, menyimpan data status kunci yang bergantung pada pengguna atau protokol lainnya. Dalam kasus ini, penyerang mungkin mencoba mengubah status kunci. Ketika pengguna lain atau protokol menggunakan status yang salah, hal ini dapat membawa risiko potensial.
Harap diperhatikan, hook di luar dua jenis ini tidak termasuk dalam ruang lingkup diskusi kami.
Setelah melakukan penelitian mendalam terhadap repositori Awesome Uniswap v4 Hooks, kami menemukan beberapa celah serius. Celah-celah 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 proyek (36%) yang memiliki kerentanan. Dari 8 proyek yang memiliki kerentanan ini, 6 memiliki masalah kontrol akses, dan 2 rentan terhadap panggilan eksternal yang tidak tepercaya.
2.1.1 Masalah Kontrol Akses
Dalam diskusi bagian ini, kami terutama fokus pada masalah yang mungkin ditimbulkan oleh fungsi callback di v4, termasuk 8 callback hook dan callback lock. Tentu saja, ada situasi lain yang perlu diverifikasi, tetapi situasi-situasi ini bervariasi berdasarkan desain dan tidak termasuk dalam lingkup diskusi kami saat ini.
Fungsi-fungsi ini seharusnya hanya dapat dipanggil oleh PoolManager, tidak dapat dipanggil oleh alamat lain ( termasuk EOA dan kontrak ). Misalnya, dalam kasus di mana hadiah didistribusikan oleh kunci kolam dana, jika fungsi yang sesuai dapat dipanggil oleh akun mana pun, maka hadiah tersebut mungkin akan diterima secara tidak benar.
Oleh karena itu, bagi hook, 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 tidak sah atau interaksi jahat dengan hook.
2.1.2 Masalah Verifikasi Input
Di Uniswap v4, karena adanya mekanisme kunci, pengguna harus mendapatkan sebuah lock melalui kontrak sebelum melakukan operasi pool dana apapun. Ini memastikan bahwa kontrak yang saat ini berpartisipasi dalam interaksi adalah kontrak locker yang terbaru.
Meski demikian, masih ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak terpercaya yang disebabkan oleh validasi input yang tidak memadai dalam beberapa implementasi Hook yang rentan:
Pertama, hook tidak memverifikasi pool dana yang ingin diinteraksi oleh pengguna. Ini bisa menjadi pool dana jahat yang mengandung token palsu dan mengeksekusi logika berbahaya.
Kedua, beberapa fungsi hook kunci memungkinkan panggilan 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 melakukan operasi di kolam dana. Saat berinteraksi dengan kolam dana, logika token jahat mengambil alih aliran kontrol untuk melakukan tindakan yang merugikan.
2.1.3 Tindakan 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 benar, serta memvalidasi 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 pool dapat mengurangi risiko yang terkait dengan ancaman semacam itu.
2.2 Masalah Keamanan dalam Model Ancaman II
Dalam model ancaman ini, kami mengasumsikan bahwa pengembang dan hook mereka bersifat jahat. Mengingat cakupannya yang luas, kami hanya fokus pada masalah keamanan yang terkait dengan versi v4. Oleh karena itu, kuncinya adalah apakah hook yang disediakan dapat menangani aset kripto yang ditransfer atau diotorisasi oleh pengguna.
Karena metode akses hook menentukan izin yang mungkin diberikan kepada hook, kami membagi hook menjadi dua kategori:
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 yang memungkinkan pengguna berinteraksi langsung.
)# 2.2.1 Hook yang Dikelola
Dalam kasus ini, aset kripto pengguna ### termasuk token asli dan token lainnya ( yang ditransfer atau diotorisasi kepada router. Karena PoolManager melakukan pemeriksaan saldo, hook jahat tidak mudah mencuri aset ini secara langsung. Namun, masih ada potensi permukaan serangan. Misalnya, mekanisme pengelolaan biaya versi v4 dapat dimanipulasi oleh penyerang melalui hook.
)# 2.2.2 Hook Mandiri
Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih kompleks. Dalam kasus ini, karena pengguna dapat berinteraksi langsung dengan hook, hook mendapatkan lebih banyak kekuasaan. Secara teoritis, hook dapat melakukan operasi 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 tampak aman mungkin menjadi berbahaya setelah peningkatan, sehingga menimbulkan risiko besar. Risiko ini termasuk:
Proksi yang dapat ditingkatkan ### dapat diserang secara langsung (;
Memiliki logika self-destruct. Dapat diserang dalam kasus pemanggilan bersama selfdestruct dan create2.
)# 2.2.3 Tindakan pencegahan terhadap model ancaman II
Poin yang sangat penting adalah menilai apakah hook tersebut bersifat jahat. Secara spesifik, untuk hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sementara untuk hook independen, fokus utamanya adalah apakah mereka dapat ditingkatkan.
![Mengapa Hook disebut sebagai "pedang bermata dua" Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Kesimpulan
Artikel ini pertama-tama memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook di Uniswap v4. Selanjutnya, kami mengajukan dua model ancaman dan memberikan ringkasan singkat tentang risiko keamanan yang terkait.
Dalam artikel selanjutnya, kami akan melakukan analisis mendalam terhadap 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.
17 Suka
Hadiah
17
5
Bagikan
Komentar
0/400
OfflineValidator
· 07-31 11:18
Masih harus memahami V4
Lihat AsliBalas0
MetaMisery
· 07-30 04:35
Tidak lebih baik daripada v3 yang stabil, ingin bermain konsep lagi, kan?
Lihat AsliBalas0
SatoshiNotNakamoto
· 07-30 04:24
Menunggu v4 muncul dengan bug
Lihat AsliBalas0
TokenGuru
· 07-30 04:17
Versi evolusi dari proyek lama, para suckers yang masuk secara membabi buta akan menderita lagi.
Lihat AsliBalas0
SigmaValidator
· 07-30 04:16
Mengerti, kesempatan shorting di lubang ini cukup bagus.
Analisis Keamanan Mekanisme Hook Uniswap v4: Inovasi dan Risiko yang Berdampingan
Dualitas Mekanisme Hook Uniswap v4: Inovasi dan Risiko Potensial yang Bersamaan
Uniswap v4 akan segera diluncurkan, dan kali ini pembaruan ini sangat ambisius. Versi baru ini akan memperkenalkan berbagai fitur 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. Dengan memanfaatkan teknologi penyimpanan transien, Uniswap v4 diperkirakan akan dirilis setelah pembaruan Ethereum Cancun.
Di antara banyak inovasi, mekanisme Hook menarik perhatian karena potensinya yang besar. Mekanisme 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 fungsionalitasnya kuat dan fleksibel, penggunaan Hook yang aman juga menghadapi tantangan yang tidak kecil. Kompleksitas Hook secara tak terhindarkan membawa vektor serangan potensial baru. Oleh karena itu, perlu untuk memperkenalkan secara sistematis masalah keamanan dan risiko potensial yang terkait dengan mekanisme Hook, untuk mendorong perkembangan keamanan komunitas, wawasan ini akan membantu membangun Hook Uniswap v4 yang lebih aman.
Artikel ini akan memperkenalkan konsep terkait mekanisme Hook dalam 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 dapat disesuaikan dan routing yang efisien di berbagai kolam.
1.1 Hook
Hook adalah kontrak yang berjalan pada berbagai tahap siklus hidup kolam dana likuiditas, tim Uniswap berharap dengan memperkenalkan Hook, siapa pun dapat membuat keputusan perdagangan. Cara ini memungkinkan dukungan asli untuk biaya dinamis, menambahkan limit order on-chain, atau menggunakan rata-rata tertimbang waktu untuk melakukan market making (TWAMM) untuk memecah pesanan besar.
Saat ini ada delapan callback Hook, dibagi menjadi empat grup ( setiap grup berisi sepasang callback ):
Tim Uniswap menyediakan beberapa contoh ( seperti cara kerja TWAMM Hook ), dan peserta komunitas juga memberikan beberapa kontribusi. Dokumentasi resmi juga menghubungkan ke repositori Awesome Uniswap v4 Hooks, yang mengumpulkan lebih banyak contoh Hook.
1.2 Singleton, pencatatan kilat, dan mekanisme kunci
Arsitektur singleton dan pencatatan kilat bertujuan untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak singleton baru, di mana semua kolam likuiditas disimpan dalam satu kontrak pintar. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.
Versi Uniswap v4 memperkenalkan pencatatan kilat dan mekanisme penguncian. Cara kerja mekanisme penguncian adalah sebagai berikut:
Kontrak locker meminta lock di PoolManager.
PoolManager menambahkan alamat kontrak locker ke antrean lockData dan memanggil callback lockAcquired.
Kontrak locker menjalankan logikanya dalam callback. Selama proses eksekusi, interaksi kontrak locker dengan pool 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 diverifikasi, PoolManager akan menghapus kontrak locker tersebut.
Singkatnya, mekanisme kunci mencegah akses bersamaan dan memastikan semua transaksi dapat diselesaikan. Kontrak locker mengajukan kunci secara berurutan, dan kemudian mengeksekusi transaksi melalui callback lockAcquired. Setiap kali operasi kolam dilakukan, callback Hook yang sesuai akan dipicu. Akhirnya, PoolManager akan memeriksa status.
Metode ini berarti bahwa penyesuaian yang dilakukan adalah pada saldo bersih internal ( yaitu delta ), dan bukan pada pelaksanaan transfer instan. Setiap modifikasi akan dicatat pada saldo internal kolam, sedangkan transfer nyata dilakukan pada akhir operasi ( yaitu lock ). Proses ini menjamin bahwa 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 kontrak. Kontrak ini berfungsi sebagai pengunci perantara, dan sebelum melakukan operasi kolam apapun, permintaan penguncian harus diajukan.
Terdapat dua skenario interaksi kontrak yang utama:
kontrak locker berasal dari repositori kode resmi atau di-deploy oleh pengguna. Situasi ini dapat dianggap sebagai interaksi melalui router.
kontrak locker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikendalikan oleh entitas pihak ketiga. Situasi ini dapat dianggap sebagai interaksi melalui Hook. Pada saat ini, Hook berperan 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 benign, tetapi terdapat kerentanan.
Model ancaman II: Hook itu sendiri adalah jahat.
Selanjutnya akan dibahas masalah keamanan potensial berdasarkan dua model ancaman ini.
2.1 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 di kontrak pintar juga dapat muncul di Hook. Misalnya, jika Hook diimplementasikan sebagai kontrak yang dapat ditingkatkan, maka mungkin akan mengalami masalah terkait yang mirip dengan kerentanan UUPSUpgradeable dari OpenZeppelin.
Mengingat faktor-faktor di atas, kami memilih untuk fokus pada potensi kerentanan yang spesifik untuk versi v4. Di Uniswap v4, Hook adalah kontrak pintar yang dapat menjalankan logika kustom sebelum atau setelah operasi dalam pool inti (, termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan ). Meskipun Hook diperkirakan akan menerapkan antarmuka standar, ia juga memungkinkan untuk menyertakan logika kustom. Oleh karena itu, ruang lingkup diskusi kami akan dibatasi pada logika yang melibatkan antarmuka Hook standar. Kemudian, kami akan mencoba mencari tahu kemungkinan sumber kerentanan, misalnya, bagaimana Hook dapat menyalahgunakan fungsi Hook standar ini.
Secara khusus, kami akan fokus pada dua jenis Hook berikut:
Jenis pertama hook, menyimpan dana pengguna. Dalam kasus ini, penyerang mungkin akan menyerang hook ini untuk memindahkan dana, menyebabkan kerugian aset.
Jenis hook kedua, menyimpan data status kunci yang bergantung pada pengguna atau protokol lainnya. Dalam kasus ini, penyerang mungkin mencoba mengubah status kunci. Ketika pengguna lain atau protokol menggunakan status yang salah, hal ini dapat membawa risiko potensial.
Harap diperhatikan, hook di luar dua jenis ini tidak termasuk dalam ruang lingkup diskusi kami.
Setelah melakukan penelitian mendalam terhadap repositori Awesome Uniswap v4 Hooks, kami menemukan beberapa celah serius. Celah-celah 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 proyek (36%) yang memiliki kerentanan. Dari 8 proyek yang memiliki kerentanan ini, 6 memiliki masalah kontrol akses, dan 2 rentan terhadap panggilan eksternal yang tidak tepercaya.
2.1.1 Masalah Kontrol Akses
Dalam diskusi bagian ini, kami terutama fokus pada masalah yang mungkin ditimbulkan oleh fungsi callback di v4, termasuk 8 callback hook dan callback lock. Tentu saja, ada situasi lain yang perlu diverifikasi, tetapi situasi-situasi ini bervariasi berdasarkan desain dan tidak termasuk dalam lingkup diskusi kami saat ini.
Fungsi-fungsi ini seharusnya hanya dapat dipanggil oleh PoolManager, tidak dapat dipanggil oleh alamat lain ( termasuk EOA dan kontrak ). Misalnya, dalam kasus di mana hadiah didistribusikan oleh kunci kolam dana, jika fungsi yang sesuai dapat dipanggil oleh akun mana pun, maka hadiah tersebut mungkin akan diterima secara tidak benar.
Oleh karena itu, bagi hook, 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 tidak sah atau interaksi jahat dengan hook.
2.1.2 Masalah Verifikasi Input
Di Uniswap v4, karena adanya mekanisme kunci, pengguna harus mendapatkan sebuah lock melalui kontrak sebelum melakukan operasi pool dana apapun. Ini memastikan bahwa kontrak yang saat ini berpartisipasi dalam interaksi adalah kontrak locker yang terbaru.
Meski demikian, masih ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak terpercaya yang disebabkan oleh validasi input yang tidak memadai dalam beberapa implementasi Hook yang rentan:
Pertama, hook tidak memverifikasi pool dana yang ingin diinteraksi oleh pengguna. Ini bisa menjadi pool dana jahat yang mengandung token palsu dan mengeksekusi logika berbahaya.
Kedua, beberapa fungsi hook kunci memungkinkan panggilan 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 melakukan operasi di kolam dana. Saat berinteraksi dengan kolam dana, logika token jahat mengambil alih aliran kontrol untuk melakukan tindakan yang merugikan.
2.1.3 Tindakan 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 benar, serta memvalidasi 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 pool dapat mengurangi risiko yang terkait dengan ancaman semacam itu.
2.2 Masalah Keamanan dalam Model Ancaman II
Dalam model ancaman ini, kami mengasumsikan bahwa pengembang dan hook mereka bersifat jahat. Mengingat cakupannya yang luas, kami hanya fokus pada masalah keamanan yang terkait dengan versi v4. Oleh karena itu, kuncinya adalah apakah hook yang disediakan dapat menangani aset kripto yang ditransfer atau diotorisasi oleh pengguna.
Karena metode akses hook menentukan izin yang mungkin diberikan kepada hook, kami membagi hook menjadi dua kategori:
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 yang memungkinkan pengguna berinteraksi langsung.
)# 2.2.1 Hook yang Dikelola
Dalam kasus ini, aset kripto pengguna ### termasuk token asli dan token lainnya ( yang ditransfer atau diotorisasi kepada router. Karena PoolManager melakukan pemeriksaan saldo, hook jahat tidak mudah mencuri aset ini secara langsung. Namun, masih ada potensi permukaan serangan. Misalnya, mekanisme pengelolaan biaya versi v4 dapat dimanipulasi oleh penyerang melalui hook.
)# 2.2.2 Hook Mandiri
Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih kompleks. Dalam kasus ini, karena pengguna dapat berinteraksi langsung dengan hook, hook mendapatkan lebih banyak kekuasaan. Secara teoritis, hook dapat melakukan operasi 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 tampak aman mungkin menjadi berbahaya setelah peningkatan, sehingga menimbulkan risiko besar. Risiko ini termasuk:
Proksi yang dapat ditingkatkan ### dapat diserang secara langsung (;
Memiliki logika self-destruct. Dapat diserang dalam kasus pemanggilan bersama selfdestruct dan create2.
)# 2.2.3 Tindakan pencegahan terhadap model ancaman II
Poin yang sangat penting adalah menilai apakah hook tersebut bersifat jahat. Secara spesifik, untuk hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sementara untuk hook independen, fokus utamanya adalah apakah mereka dapat ditingkatkan.
![Mengapa Hook disebut sebagai "pedang bermata dua" Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Kesimpulan
Artikel ini pertama-tama memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook di Uniswap v4. Selanjutnya, kami mengajukan dua model ancaman dan memberikan ringkasan singkat tentang risiko keamanan yang terkait.
Dalam artikel selanjutnya, kami akan melakukan analisis mendalam terhadap masalah keamanan di bawah setiap model ancaman.