Saya yakin Uniswap v4 akan segera tersedia untuk semua orang!

Kali ini tim Uniswap memiliki tujuan dan rencana ambisius untuk memperkenalkan banyak fitur baru [1], termasuk dukungan untuk kumpulan likuiditas dalam jumlah tidak terbatas dan biaya dinamis untuk setiap pasangan perdagangan, desain tunggal, akuntansi kilat, Hooks, dan dukungan untuk token ERC1155 standar. Memanfaatkan penyimpanan sementara yang diperkenalkan oleh EIP-1153, Uniswap v4 diharapkan akan dirilis setelah peningkatan Ethereum Cancun.

Di antara banyak inovasi, mekanisme Hook telah menarik perhatian luas karena potensinya yang kuat. Mekanisme Hook mendukung eksekusi kode tertentu pada titik tertentu dalam siklus hidup kumpulan likuiditas, sehingga sangat meningkatkan skalabilitas dan fleksibilitas kumpulan.

Namun mekanisme pengait juga bisa menjadi pedang bermata dua. Meskipun kuat dan fleksibel, menggunakan Hook dengan aman juga merupakan tantangan besar. Kompleksitas kait pasti membawa potensi vektor serangan baru. Oleh karena itu, kami berharap dapat menulis serangkaian artikel untuk memperkenalkan secara sistematis masalah keamanan dan potensi risiko terkait mekanisme Hook, sehingga dapat mendorong pengembangan keamanan komunitas. Kami percaya bahwa wawasan ini akan membantu membangun Uniswap v4 Hook yang aman.

Sebagai awal dari rangkaian artikel ini, artikel ini memperkenalkan konsep terkait mekanisme Hook di Uniswap v4 dan menguraikan risiko keamanan mekanisme Hook.

Mekanisme Uniswap V4

Sebelum kita mendalaminya, kita perlu memiliki pemahaman dasar tentang mekanisme Uniswap v4. Menurut pengumuman resmi [1] dan kertas putih [2], Hooks, arsitektur singleton, dan akuntansi kilat adalah tiga fungsi penting untuk mengimplementasikan kumpulan likuiditas khusus dan mencapai perutean yang efisien di beberapa kumpulan.

1.1 Kait

Hooks mengacu pada kontrak yang berjalan pada berbagai tahap siklus hidup kumpulan likuiditas. Tim Uniswap berharap memungkinkan siapa pun membuat keputusan trade-off dengan memperkenalkan Hooks. Dengan cara ini, dimungkinkan untuk mendukung biaya dinamis secara asli, menambahkan pesanan batas harga on-chain, atau menyebarkan pesanan dalam jumlah besar melalui pembuat pasar rata-rata tertimbang waktu (TWAMM).

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

  • sebelum Inisialisasi/setelah Inisialisasi

  • sebelumModifyPosition/setelahModifyPosition

  • sebelum Swap/setelah Swap

  • sebelum Donasi/setelah Donasi

Berikut ini adalah proses pertukaran Hooks yang diperkenalkan di kertas putih [2].

Gambar 1: Proses Exchange Hook

Tim Uniswap memperkenalkan cara melakukannya dengan beberapa contoh (seperti TWAMM Hook[3]), dan peserta komunitas juga memberikan beberapa kontribusi. Dokumentasi resmi[4] juga tertaut ke repositori Awesome Uniswap v4 Hooks[5], yang mengumpulkan lebih banyak contoh Hook.

1.2 Singleton, penghitungan petir dan mekanisme penguncian

Arsitektur Singleton dan akuntansi flash dirancang untuk meningkatkan kinerja dengan mengurangi biaya dan memastikan efisiensi. Ini memperkenalkan kontrak tunggal baru, di mana semua kumpulan likuiditas disimpan dalam kontrak pintar yang sama. Desain tunggal ini bergantung pada PoolManager untuk menyimpan dan mengelola status semua kumpulan.

Pada versi protokol Uniswap sebelumnya, operasi seperti pertukaran atau penambahan likuiditas melibatkan transfer token langsung. Versi v4 berbeda karena memperkenalkan akuntansi kilat dan mekanisme kunci.

Mekanisme pengunciannya bekerja sebagai berikut:

1. Kontrak loker meminta kunci pada PoolManager.

2. PoolManager menambahkan alamat kontrak loker ke antrian lockData dan memanggil callback lockAcquired-nya.

3. Kontrak loker menjalankan logikanya dalam panggilan balik. Selama eksekusi, interaksi kontrak loker dengan pool dapat mengakibatkan kenaikan mata uang yang tidak nol. Namun, pada akhir eksekusi, semua delta harus mencapai nol. Selain itu, jika antrian lockData tidak kosong, hanya kontrak loker terakhir yang dapat melakukan operasi.

4. PoolManager memeriksa status antrian lockData dan kenaikan mata uang. Setelah verifikasi, PoolManager akan menghapus kontrak loker.

Singkatnya, mekanisme penguncian mencegah akses bersamaan dan memastikan bahwa semua transaksi dapat diselesaikan. Kontrak loker berlaku untuk kunci secara berurutan, dan kemudian mengeksekusi transaksi melalui panggilan balik lockAcquired. Callback Hook yang sesuai akan dipicu sebelum dan sesudah setiap operasi kumpulan. Terakhir, PoolManager memeriksa statusnya.

Pendekatan ini berarti bahwa operasi menyesuaikan saldo bersih internal (yaitu delta) daripada melakukan transfer instan. Setiap modifikasi akan dicatat dalam saldo internal kumpulan, dan transfer sebenarnya akan dilakukan pada akhir operasi (yaitu kunci). Proses ini memastikan tidak ada token yang beredar, sehingga menjaga integritas dana.

Karena mekanisme penguncian, Akun Kepemilikan Eksternal (EOA) tidak dapat berinteraksi langsung dengan PoolManager. Sebaliknya, interaksi apa pun harus terjadi melalui kontrak. Kontrak ini bertindak sebagai loker perantara dan perlu meminta kunci sebelum melakukan operasi kumpulan apa pun.

Ada dua skenario interaksi kontrak utama:

  • Kontrak loker tertentu berasal dari basis kode resmi atau diterapkan oleh pengguna. Dalam hal ini, kita dapat menganggap interaksinya melalui router.

  • Kontrak loker dan Hook diintegrasikan ke dalam kontrak yang sama, atau dikendalikan oleh entitas pihak ketiga. Untuk kasus ini, kita dapat menganggap interaksi terjadi melalui Hooks. Dalam hal ini, Hook berperan sebagai kontrak loker dan bertanggung jawab menangani panggilan balik.

Model ancaman

Sebelum membahas masalah keamanan terkait, kita perlu mengidentifikasi model ancamannya. Kami terutama mempertimbangkan dua situasi berikut:

  • Model Ancaman I: Kait itu sendiri tidak berbahaya, namun memiliki kerentanan.

  • Model Ancaman II: Kait pada dasarnya berbahaya.

Pada bagian berikut, kami membahas potensi masalah keamanan berdasarkan dua model ancaman ini.

2.1 Masalah keamanan pada model ancaman I

Model Ancaman I berfokus pada kerentanan yang terkait dengan Hook itu sendiri. Model ancaman ini mengasumsikan bahwa pengembang dan Hooks mereka tidak berbahaya. Namun, kerentanan yang diketahui dalam kontrak pintar juga dapat muncul di Hooks. Misalnya, jika Hook diimplementasikan sebagai kontrak yang dapat diupgrade, Hook mungkin mengalami masalah serupa dengan kerentanan UUPSUpgradeable OpenZeppelin.

Mengingat faktor-faktor di atas, kami memilih untuk fokus pada potensi kerentanan yang unik pada versi v4. Di Uniswap v4, Hooks adalah kontrak pintar yang mampu menjalankan logika khusus sebelum atau sesudah operasi kumpulan inti, termasuk inisialisasi, modifikasi posisi, pertukaran, dan pengumpulan. Meskipun Hooks diharapkan mengimplementasikan antarmuka standar, Hooks juga memungkinkan penyertaan logika khusus. Oleh karena itu, pembahasan kita akan dibatasi pada logika yang melibatkan antarmuka Hook standar. Kami kemudian akan mencoba mengidentifikasi kemungkinan sumber kerentanan, misalnya, bagaimana Hooks dapat menyalahgunakan fungsi standar Hook ini.

Secara khusus, kami akan fokus pada dua jenis Hooks berikut:

  • Kait pertama adalah menyimpan dana pengguna. Dalam kasus ini, penyerang mungkin menyerang hook ini untuk mentransfer dana, sehingga menyebabkan kerugian aset.

  • Jenis hook kedua menyimpan data status kunci yang diandalkan oleh pengguna atau protokol lain. Dalam hal ini, penyerang mungkin mencoba mengubah keadaan kritis. Potensi risiko dapat muncul ketika pengguna atau protokol lain menggunakan status yang salah.

Harap dicatat bahwa kaitan di luar kedua cakupan ini berada di luar cakupan diskusi kita.

Karena tidak ada kasus penggunaan nyata untuk Hooks pada saat penulisan ini, kami akan mengambil beberapa informasi dari repositori Awesome Uniswap v4 Hooks.

Setelah mendalami repositori Awesome Uniswap v4 Hooks (melakukan hash 3a0a444922f26605ec27a41929f3ced924af6075), kami menemukan beberapa kerentanan kritis. Kerentanan ini terutama berasal dari interaksi berisiko antara hooks, PoolManager, dan pihak ketiga eksternal, dan dapat dibagi menjadi dua kategori: masalah kontrol akses dan masalah validasi input. Silakan lihat tabel di bawah untuk temuan spesifik:

Secara total, kami menemukan 22 proyek yang relevan (tidak termasuk proyek yang tidak terkait dengan Uniswap v4). Di antara proyek-proyek tersebut, kami yakin terdapat 8 (36%) proyek yang rentan. Dari delapan proyek yang rentan, enam proyek memiliki masalah kontrol akses dan dua proyek rentan terhadap panggilan eksternal yang tidak dipercaya.

2.1.1 Masalah kontrol akses

Pada bagian diskusi ini, kami terutama berfokus pada masalah yang mungkin disebabkan oleh fungsi callback di v4, termasuk 8 callback hook dan callback lock. Tentu saja, ada situasi-situasi lain yang perlu diverifikasi, namun situasi-situasi ini berbeda-beda berdasarkan rancangannya dan berada di luar cakupan diskusi kita.

Fungsi-fungsi ini hanya boleh dipanggil oleh PoolManager dan tidak dapat dipanggil oleh alamat lain (termasuk EOA dan kontrak). Misalnya, jika hadiah didistribusikan berdasarkan kunci kumpulan, hadiah mungkin salah diklaim jika fungsi terkait dapat dipanggil oleh akun mana pun.

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

2.1.2 Masalah verifikasi masukan

Di Uniswap v4, karena mekanisme kunci, pengguna harus mendapatkan kunci melalui kontrak sebelum melakukan operasi pengumpulan dana apa pun. Hal ini memastikan bahwa kontrak yang saat ini berpartisipasi dalam interaksi adalah kontrak loker terbaru.

Namun, ada kemungkinan skenario serangan, yaitu panggilan eksternal yang tidak tepercaya karena validasi input yang tidak tepat di beberapa implementasi Hook yang rentan:

  • Pertama, hook tidak memverifikasi kumpulan dana yang ingin digunakan pengguna untuk berinteraksi. Ini bisa jadi merupakan kumpulan berbahaya yang berisi token palsu dan menjalankan logika berbahaya.

  • Kedua, beberapa fungsi pengait tombol memungkinkan panggilan eksternal sewenang-wenang.

Panggilan eksternal yang tidak tepercaya sangat berbahaya karena dapat menyebabkan berbagai jenis serangan, termasuk apa yang kita kenal sebagai serangan masuk kembali.

Untuk menyerang hook yang rentan ini, penyerang dapat mendaftarkan kumpulan dana berbahaya untuk token palsu miliknya, dan kemudian memanggil hook tersebut untuk melakukan operasi di kumpulan dana tersebut. Saat berinteraksi dengan kumpulan, logika token berbahaya membajak aliran kontrol untuk terlibat dalam perilaku yang tidak diinginkan.

2.1.3 Tindakan pencegahan terhadap ancaman model I

Untuk menghindari masalah keamanan terkait hook, sangat penting untuk mengautentikasi interaksi dengan menerapkan kontrol akses yang diperlukan secara tepat ke fungsi eksternal/publik yang sensitif dan memvalidasi parameter input. Selain itu, perlindungan masuk kembali dapat membantu memastikan bahwa hook tidak dieksekusi berulang kali dalam aliran logika standar. Dengan menerapkan perlindungan keamanan yang tepat, kumpulan dapat mengurangi risiko yang terkait dengan ancaman tersebut.

2.2 Masalah Keamanan pada Model Ancaman II

Dalam model ancaman ini, kami berasumsi bahwa pengembang dan pengaitnya berbahaya. Karena 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 mengakses hook menentukan izin yang dapat diberikan kepada hook, kami membagi hook menjadi dua kategori:

  • Kait Terkelola: Kait bukanlah titik masuk. Pengguna harus berinteraksi dengan hook melalui router (mungkin disediakan oleh Uniswap).

  • Standalone Hooks: Hooks adalah titik masuk yang memungkinkan pengguna berinteraksi dengannya secara langsung.

Gambar 2: Contoh Hook yang berbahaya

2.2.1 Kait Terkelola

Dalam hal ini, aset kripto pengguna (termasuk token asli dan token lainnya) ditransfer atau diotorisasi ke router. Karena PoolManager melakukan pemeriksaan saldo, tidak mudah bagi pelaku kejahatan untuk mencuri aset ini secara langsung. Namun, masih ada potensi serangan permukaan. Misalnya, mekanisme manajemen pengeluaran versi v4 dapat dimanipulasi oleh penyerang melalui hook.

2.2.2 Kait Independen

Situasi menjadi lebih rumit ketika Hooks digunakan sebagai titik masuk. Dalam hal ini, pengait memperoleh kekuatan lebih besar karena pengguna dapat berinteraksi dengannya secara langsung. Secara teori, hook dapat melakukan apapun yang diinginkannya dengan interaksi ini.

Pada versi v4, verifikasi logika kode sangat penting. Masalah utamanya adalah apakah logika kode dapat dimanipulasi. Jika sebuah hook dapat diupgrade, ini berarti hook yang tampaknya aman mungkin menjadi berbahaya setelah diupgrade, sehingga menimbulkan risiko yang signifikan. Risiko-risiko ini meliputi:

  • Agen yang dapat diupgrade (dapat diserang secara langsung);

  • Dengan logika penghancuran diri. Ini mungkin diserang ketika selfdestruct dan create2 dipanggil secara bersamaan.

2.2.3 Tindakan pencegahan terhadap ancaman model II

Penting untuk mengevaluasi apakah pengait tersebut berbahaya. Khususnya, untuk hook yang dikelola, kita harus fokus pada perilaku pengelolaan biaya; sedangkan untuk hook yang berdiri sendiri, fokus utamanya adalah apakah hook tersebut dapat diupgrade.

Kesimpulannya

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

Pada artikel berikutnya, kami akan melakukan analisis mendalam mengenai masalah keamanan pada setiap model ancaman.