Uniswap v4推出在即，Hook機制潛藏安全隱患

Uniswap v4即將發布,這次更新引入了諸多全新功能,包括支持每個交易對無限數量的流動性池和動態費用、單例設計、閃電記帳、Hook機制,以及對ERC1155代幣標準的支持。預計v4將在以太坊坎昆升級後推出。

在衆多創新中,Hook機制因其強大潛力而備受關注。它允許在流動性池生命週期的特定時點執行自定義代碼,大大增強了池子的可擴展性和靈活性。

然而,Hook機制也可能是把雙刃劍。盡管功能強大且靈活,但安全使用Hook同樣面臨挑戰。Hook的復雜性不可避免地帶來了新的潛在攻擊向量。因此,系統性地介紹Hook機制相關的安全問題與潛在風險顯得尤爲重要,這將有助於構建更安全的Uniswap v4 Hook。

本文將介紹Uniswap v4中Hook機制的相關概念,並概述其存在的安全風險。

Uniswap V4的機制

在深入探討之前,我們需要對Uniswap v4的機制有基本了解。根據官方公告和白皮書,Hook、單例架構和閃電記帳是實現自定義流動性池和跨多個池子高效路由的三個重要功能。

Hook

Hook指在流動性資金池生命週期不同階段運行的合約,Uniswap團隊希望通過引入Hook使任何人都能做出權衡決策。這種方式可以實現原生支持動態費用、添加鏈上限價單,或者通過時間加權平均做市商(TWAMM)分散大訂單。

目前有八個Hook回調,分爲四組(每組包含一對回調):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• beforeSwap/afterSwap
• beforeDonate/afterDonate

單例、閃電記帳和鎖機制

單例架構和閃電記帳旨在通過降低成本和確保效率來提高性能。它引入了一種新的singleton合約,即所有流動性池都保存在同一個智能合約中。這個單例設計依賴一個PoolManager來存儲和管理所有池子的狀態。

v4版本引入了閃電記帳和鎖機制。鎖機制的運作方式如下:

1. locker合約在PoolManager上請求lock。

2. PoolManager將該locker合約地址添加到lockData隊列,並調用其lockAcquired回調。

3. locker合約在回調中執行其邏輯。執行過程中,locker合約與池子的交互可能導致非零的貨幣增量。然而,執行結束時,所有增量必須結算爲零。另外,如果lockData隊列不爲空,只有最後一個locker合約可以執行操作。

4. PoolManager檢查lockData隊列和貨幣增量的狀態。驗證後,PoolManager將刪除該locker合約。

總之,鎖機制防止了並發訪問,並保證了所有交易都能被清算。locker合約按順序申請lock,然後通過lockAcquired回調執行交易。每次池操作前後會觸發對應的Hook回調。最後,PoolManager會檢查狀態。

這種方法意味着操作調整的是內部淨餘額(即delta),而不是執行即時轉帳。任何修改都會記錄在池子的內部餘額中,實際的轉帳則在操作(即lock)結束時進行。這個過程保證了沒有未清算的代幣,從而維持了資金的完整性。

由於鎖機制的存在,外部所有帳戶(EOA)不能直接與PoolManager交互。相反,任何交互都必須通過一個合約進行。該合約作爲中間的locker,在進行任何池操作之前都需要請求lock。

主要存在兩種合約交互場景:

• locker合約來自官方代碼庫,或者由用戶部署。在這種情況下,我們可以將交互視爲通過路由器進行。

• locker合約和Hook集成到同一個合約中,或由第三方實體控制。對於這種情況,我們可以將交互視爲通過Hook進行。在這種情況下,Hook既扮演了locker合約的角色,又負責處理回調。

威脅模型

在討論相關的安全問題之前,我們需要確定威脅模型。主要考慮以下兩種情況:

• 威脅模型I:Hook本身是良性的,但存在漏洞。

• 威脅模型II:Hook本身就是惡意的。

在接下來的部分,我們將根據這兩種威脅模型討論潛在的安全問題。

威脅模型I中的安全問題

威脅模型I關注的是與Hook本身相關的漏洞。這個威脅模型假設開發者及其Hook是無惡意的。然而,智能合約現有的已知漏洞也可能出現在Hook中。

我們選擇聚焦於v4版本特有的潛在漏洞。在Uniswap v4中,Hook是能夠在核心池操作(包括初始化、修改位置、交換和收集)之前或之後執行自定義邏輯的智能合約。雖然Hook預計將實現標準的接口,但它也允許包含自定義邏輯。因此,我們的討論範圍將限制在涉及標準Hook接口的邏輯。然後,我們將嘗試找出可能的漏洞來源,例如,Hook可能如何濫用這些標準Hook函數。

具體來說,我們將關注以下兩種Hook:

• 第一種hook,保管用戶資金。在這種情況下,攻擊者可能會攻擊這個hook來轉移資金,造成資產損失。

• 第二種hook,存儲用戶或其他協議依賴的關鍵狀態數據。在這種情況下,攻擊者可能會試圖改變關鍵狀態。當其他用戶或協議使用錯誤狀態時,可能會帶來潛在風險。

在對Awesome Uniswap v4 Hooks倉庫進行深入研究後,我們發現了幾個嚴重的漏洞。這些漏洞主要源於hook、PoolManager以及外部第三方之間的風險交互,主要可以分爲兩類:訪問控制問題和輸入驗證問題。

總的來說,我們發現了22個相關項目(排除與Uniswap v4無關的項目)。在這些項目中,我們認爲有8個(36%)項目是存在漏洞的。在這8個有漏洞的項目中,6個存在訪問控制問題,2個容易受到不受信任的外部調用。

訪問控制問題

在這部分討論中,我們主要關注的是v4中的回調函數可能導致的問題,包括8個hook回調和lock回調。這些函數應該只能被PoolManager調用,不能被其他地址(包括EOA和合約)調用。例如,在獎勵由資金池密鑰分發的情況下,如果相應的函數可以由任意帳戶調用,那麼獎勵可能會被錯誤地領取。

因此,對於hook來說,建立強大的訪問控制機制是至關重要的,尤其是它們可以被除了池子本身之外的其他方調用。通過嚴格管理訪問權限,流動性池可以顯著降低與hook未授權交互或惡意交互的風險。

輸入驗證問題

在Uniswap v4中,由於存在鎖機制,用戶在執行任何資金池操作之前必須通過合約獲得一個lock。這確保了當前參與交互的合約是最新的locker合約。

盡管如此,仍然存在一個可能的攻擊場景,即由於在一些易受攻擊的Hook實現中輸入驗證不當而導致的不受信任的外部調用:

• 首先,hook並未驗證用戶打算交互的資金池。這可能是一個含有虛假代幣並執行有害邏輯的惡意資金池。

• 其次,一些關鍵的hook函數允許任意的外部調用。

不受信任的外部調用極其危險,因爲它可能導致各種類型的攻擊,包括我們熟知的重入攻擊。

爲了攻擊這些易受攻擊的hook,攻擊者可以爲自己的虛假代幣註冊一個惡意資金池,然後調用hook在資金池執行操作。在與資金池交互時,惡意代幣邏輯劫持控制流以便進行不良行爲。

針對威脅模型I的防範措施

爲了規避與hook相關的此類安全問題,通過適當執行對敏感的外部/公共函數的必要訪問控制,並對輸入參數進行驗證,從而對交互進行驗證是至關重要的。此外,重入保護可能有助於確保hook不會在標準邏輯流程中被重復執行。通過實施適當的安全防護措施,資金池可以降低與此類威脅相關的風險。

威脅模型II中的安全問題

在這個威脅模型中,我們假設開發者及其hook是惡意的。鑑於涉及範圍很廣,我們僅關注與v4版本相關的安全問題。因此,關鍵在於提供的hook是否能夠處理用戶轉帳或授權的加密資產。

由於訪問hook的方法決定了可能賦予hook的權限,我們據此將hook分爲兩類:

• 托管型Hook(Managed Hooks):hook不是入口點。用戶必須通過路由器(可能由Uniswap提供)與hook進行交互。

• 獨立型Hook(Standalone Hooks):hook是入口點,允許用戶直接與之交互。

托管型Hook

在這種情況下,用戶的加密資產(包括原生代幣和其他代幣)被轉帳或授權給router。由於PoolManager執行了餘額檢查,惡意hook不容易直接竊取這些資產。然而,仍然存在潛在的攻擊面。例如,v4版本的費用管理機制可能會被攻擊者通過hook進行操縱。

獨立型Hook

當Hook被用作入口點時,情況就更加復雜。在這種情況下,由於用戶可以直接與hook進行交互,hook獲得了更多的權力。理論上,hook可以通過這種交互執行想要的任何操作。

在v4版本中,代碼邏輯的驗證是非常關鍵的。主要問題在於是否可以操縱代碼邏輯。如果hook是可升級的,這意味着一個看似安全的hook可能會在升級之後成爲惡意的,從而構成重大風險。這些風險包括:

• 可升級的代理(可以被直接攻擊)；

• 帶有自毀邏輯。在聯合調用selfdestruct和create2的情況下可能被攻擊。

針對威脅模型II的防範措施

至關重要的一點在於評估hook是否是惡意的。具體來說,對於托管型hook,我們應該關注費用管理的行爲；而對於獨立型hook,主要的關注點在於它們是否可升級。

結論

本文簡要概述了與Uniswap v4的Hook安全問題相關的核心機制,提出了兩種威脅模型並概述了相關的安全風險。

在後續文章中,我們將對每種威脅模型下的安全問題進行深入分析。