Mengapa Hook disebut sebagai "pedang bermata dua" Uniswap V4?

Uniswap v4 diharapkan akan segera hadir. Kali ini tim Uniswap menetapkan tujuan besar, berencana untuk memperkenalkan berbagai fitur baru, termasuk dukungan untuk jumlah tak terbatas dari kolam likuiditas untuk setiap pasangan perdagangan dan biaya dinamis, desain tunggal, pembukuan kilat, Hook, serta dukungan untuk standar token ERC1155. Dengan memanfaatkan penyimpanan transien, Uniswap v4 diperkirakan akan dirilis setelah pembaruan Ethereum Cancun.

Di antara banyak inovasi, mekanisme Hook mendapat perhatian luas karena potensi kuatnya. Ini mendukung eksekusi kode tertentu pada titik tertentu dalam siklus hidup kolam likuiditas, secara signifikan meningkatkan skalabilitas dan fleksibilitas kolam tersebut.

Namun, mekanisme Hook juga bisa menjadi pedang bermata dua. Meskipun fungsionalitasnya yang kuat dan fleksibel, penggunaan Hook yang aman juga merupakan tantangan yang tidak kecil. Kompleksitas Hook secara tidak terhindarkan membawa potensi vektor serangan baru. Oleh karena itu, kami berharap melalui serangkaian artikel, dapat memperkenalkan secara sistematis masalah keamanan dan risiko potensial yang terkait dengan mekanisme Hook, untuk mendorong perkembangan keamanan komunitas, dan kami percaya wawasan ini akan membantu membangun Hook Uniswap v4 yang aman.

Sebagai karya pembuka dari seri artikel ini, artikel ini memperkenalkan konsep-konsep yang terkait dengan mekanisme Hook di Uniswap v4 dan memberikan gambaran tentang risiko keamanan yang ada pada mekanisme Hook.

Mekanisme Uniswap V4

Sebelum membahas lebih dalam, kita perlu memiliki pemahaman dasar tentang mekanisme Uniswap v4. Hook, arsitektur single-instance, dan pembukuan kilat adalah tiga fungsi penting untuk mewujudkan kolam likuiditas yang disesuaikan dan melakukan routing yang efisien di berbagai kolam.

1.1 Kait

Hook mengacu pada kontrak yang berjalan pada berbagai tahap siklus hidup kolam dana likuiditas, tim Uniswap berharap dengan memperkenalkan Hook, siapa pun dapat membuat keputusan perdagangan. Dengan cara ini, dukungan asli untuk biaya dinamis, menambahkan pesanan batas on-chain, atau melalui pembuat pasar rata-rata berbobot waktu (TWAMM) untuk mendiversifikasi pesanan besar dapat dicapai.

Saat ini ada delapan callback Hook, dibagi menjadi empat grup (setiap grup berisi sepasang callback):

• sebelumInisialisasi/setelahInisialisasi

• sebelumUbahPosisi/setelahUbahPosisi

• sebelumSwap/setelahSwap

• sebelumDonasi/setelahDonasi

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 kontrak pintar yang sama. Desain singleton ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kolam.

Dalam versi awal protokol Uniswap, operasi seperti pertukaran atau menambahkan likuiditas melibatkan transfer token langsung, sedangkan versi v4 berbeda karena memperkenalkan akuntansi kilat dan mekanisme penguncian.

Cara kerja mekanisme kunci adalah sebagai berikut:

1. Sebuah kontrak locker meminta lock di PoolManager.

2. PoolManager menambahkan alamat kontrak locker ke dalam antrean lockData dan memanggil callback lockAcquired.

3. Kontrak locker ini mengeksekusi 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.

4. PoolManager memeriksa status antrean lockData dan peningkatan mata uang. Setelah diverifikasi, PoolManager akan menghapus kontrak locker tersebut.

Secara ringkas, mekanisme penguncian mencegah akses bersamaan dan memastikan bahwa semua transaksi dapat diselesaikan. Kontrak locker mengajukan penguncian secara berurutan, kemudian mengeksekusi transaksi melalui callback lockAcquired. Sebelum dan sesudah setiap operasi pool, callback Hook yang sesuai akan dipicu. Terakhir, PoolManager akan memeriksa status.

Metode ini berarti bahwa penyesuaian yang dilakukan adalah pada saldo bersih internal, bukan melakukan transfer instan. Setiap modifikasi akan dicatat dalam saldo internal kolam, sedangkan transfer sebenarnya dilakukan pada akhir operasi. Proses ini memastikan 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 sebuah kontrak. Kontrak ini bertindak sebagai locker perantara, dan sebelum melakukan operasi pool apa pun, perlu meminta kunci.

Ada dua skenario interaksi kontrak utama:

• Kontrak locker tertentu berasal dari repositori kode resmi, atau dikerahkan oleh pengguna. Dalam hal ini, kita dapat menganggap interaksi sebagai melalui router.

• Kontrak locker tertentu diintegrasikan ke dalam kontrak yang sama dengan Hook, atau dikendalikan oleh entitas pihak ketiga. Untuk situasi ini, kita dapat menganggap interaksi dilakukan 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. Kami terutama mempertimbangkan dua situasi berikut:

• Model ancaman I: Hook itu sendiri bersifat baik, tetapi memiliki celah.

• Model ancaman II: Hook itu sendiri jahat.

Dalam bagian berikut, kami akan membahas potensi masalah keamanan berdasarkan kedua 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 dalam kontrak pintar juga dapat muncul dalam Hook. Misalnya, jika Hook diimplementasikan sebagai kontrak yang dapat diperbarui, maka ia dapat menghadapi masalah terkait yang mirip dengan kerentanan UUPSUpgradeable dari OpenZeppelin.

Mengingat faktor-faktor di atas, kami memilih untuk fokus pada potensi kerentanan yang khusus untuk versi v4. Di Uniswap v4, Hook adalah kontrak pintar yang dapat menjalankan logika kustom sebelum atau setelah operasi pada kolam inti (termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan). Meskipun Hook diharapkan akan mengimplementasikan 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 sumber potensi kerentanan, misalnya, bagaimana Hook dapat menyalahgunakan fungsi Hook standar ini.

Secara spesifik, kita akan fokus pada dua jenis Hook berikut:

• Jenis pertama hook, menjaga dana pengguna. Dalam kasus ini, penyerang mungkin akan menyerang hook ini untuk memindahkan dana, menyebabkan kerugian aset.

• Jenis hook kedua, menyimpan data status kritis yang bergantung pada pengguna atau protokol lainnya. Dalam hal ini, penyerang mungkin mencoba mengubah status kritis. Ketika pengguna atau protokol lain menggunakan status yang salah, ini dapat membawa risiko potensial.

Harap dicatat bahwa hook di luar dua rentang ini tidak termasuk dalam diskusi kami.

Secara keseluruhan, kami menemukan 22 proyek terkait (mengeluarkan 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 bagian diskusi ini, kami terutama berfokus 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 ini bervariasi karena desainnya dan tidak termasuk dalam ruang lingkup diskusi kami.

Fungsi-fungsi ini hanya boleh dipanggil oleh PoolManager, dan tidak boleh dipanggil oleh alamat lain (termasuk EOA dan kontrak). Misalnya, dalam kasus di mana hadiah didistribusikan oleh kunci kolam, jika fungsi yang sesuai dapat dipanggil oleh sembarang akun, maka hadiah tersebut mungkin akan diterima secara salah.

Oleh karena itu, bagi hook, sangat penting untuk membangun mekanisme kontrol akses yang kuat, terutama karena mereka dapat dipanggil oleh pihak lain selain kolam itu sendiri. Dengan mengelola hak akses secara ketat, kolam likuiditas dapat secara signifikan mengurangi risiko interaksi tidak sah atau interaksi jahat dengan hook.

2.1.2 Masalah Verifikasi Input

Dalam Uniswap v4, karena adanya mekanisme kunci, pengguna harus mendapatkan sebuah lock melalui kontrak sebelum melakukan operasi pada kumpulan dana. Ini memastikan bahwa kontrak yang saat ini berinteraksi adalah kontrak locker terbaru.

Meskipun demikian, masih ada skenario serangan yang mungkin terjadi, 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 jadi kolam dana jahat yang mengandung token palsu dan menjalankan logika berbahaya.

• Kedua, beberapa fungsi hook kunci memungkinkan pemanggilan eksternal secara sembarangan.

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 pada fungsi eksternal/publik yang sensitif dan 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, pool dana 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 lingkup yang luas, kami hanya fokus pada masalah keamanan yang terkait dengan versi v4. Oleh karena itu, kuncinya adalah apakah hook yang disediakan dapat menangani transfer atau otorisasi aset kripto pengguna.

Karena metode akses hook menentukan kemungkinan hak akses yang diberikan kepada hook, kami membagi hook menjadi dua kategori:

• Hook yang Dikelola: hook bukanlah titik masuk. Pengguna harus berinteraksi dengan hook melalui router (mungkin disediakan oleh Uniswap).

• Hook tipe independen: hook adalah titik masuk yang memungkinkan pengguna berinteraksi langsung dengannya.

2.2.1 Hook Terkelola

Dalam hal ini, aset kripto pengguna (termasuk token asli dan token lainnya) ditransfer atau diberi otorisasi kepada router. Karena PoolManager melakukan pemeriksaan saldo, hook jahat tidak mudah mencuri aset ini secara langsung. Namun, masih ada potensi vektor serangan. Misalnya, mekanisme manajemen biaya versi v4 mungkin dimanipulasi oleh penyerang melalui hook.

2.2.2 Tipe Mandiri Hook

Ketika Hook digunakan sebagai titik masuk, situasinya menjadi lebih kompleks. Dalam kasus ini, karena pengguna dapat berinteraksi langsung dengan hook, hook mendapatkan 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 mungkin menjadi jahat setelah peningkatan, sehingga menimbulkan risiko besar. Risiko ini termasuk:

• Proxy yang dapat ditingkatkan (dapat diserang secara langsung);

• Memiliki logika penghancuran diri. Dalam kasus panggilan bersamaan selfdestruct dan create2, dapat diserang.

2.2.3 Langkah-langkah pencegahan untuk model ancaman II

Poin penting adalah menilai apakah hook bersifat jahat. Secara khusus, untuk hook yang dikelola, kita harus memperhatikan perilaku manajemen biaya; sedangkan untuk hook independen, perhatian utama adalah apakah mereka dapat ditingkatkan.

Kesimpulan

Dalam artikel ini, kami pertama-tama memberikan gambaran singkat tentang mekanisme inti yang terkait dengan masalah keamanan Hook pada Uniswap v4. Selanjutnya, kami mengusulkan dua model ancaman dan memberikan gambaran singkat tentang risiko keamanan yang relevan.

Dalam artikel selanjutnya, kami akan membahas setiap model ancaman.