Source: BlockSec 

Believe that Uniswap v4 will be with us soon!

This time, the Uniswap team has set ambitious goals, planning to introduce many new features [1], including unlimited liquidity pools and dynamic fees for each trading pair, singleton design, lightning-fast accounting, Hooks, and support for the ERC1155 token standard. Using the transient storage introduced by EIP-1153, Uniswap v4 is expected to be released after the Ethereum Cancun upgrade.

Among many innovations, the Hook mechanism has attracted widespread attention due to its powerful potential. The Hook mechanism supports the execution of specific code at specific points in the liquidity pool's lifecycle, greatly enhancing the scalability and flexibility of the pool. However, the Hook mechanism can also be a double-edged sword. Although it is powerful and flexible, using Hook safely is also a significant challenge.

The complexity of Hooks inevitably brings new potential attack vectors. Therefore, we hope to write a series of articles to systematically introduce the security issues and potential risks related to the Hook mechanism, in order to promote the security development of the community. We believe that these insights will help build a secure Uniswap v4 Hook. As the opening article of this series, this article introduces the concept related to the Hook mechanism in Uniswap v4 and outlines the security risks associated with the Hook mechanism.

1 - Mechanism of Uniswap V4

Before delving deeper, we need to have a basic understanding of the mechanism of Uniswap v4.

According to the official announcement [1] and white paper [2], Hook, singleton architecture, and lightning accounting are the three important functions for implementing custom liquidity pools and efficient routing across multiple pools.    1.1 Hook refers to the contract that runs at different stages of the liquidity pool lifecycle. The Uniswap team hopes to introduce Hook to enable anyone to make trade-offs. In this way, it is possible to natively support dynamic fees, add on-chain limit orders, or decentralize large orders through time-weighted average market makers (TWAMM).

Currently, there are eight Hook callbacks, divided into four groups (each group contains a pair of callbacks):

- beforeInitialize/afterInitialize

- beforeModifyPosition/afterModifyPosition

- beforeSwap/afterSwap

- beforeDonate/afterDonate

The following is the process of the exchange Hook introduced in the white paper [2].

Figure 1: Exchange Hook Process

Uniswap team introduced the operation method with some examples (such as TWAMM Hook[3]), and community participants also made some contributions. The official documentation [4] also links to the Awesome Uniswap v4 Hooks[5] repository, which collects more Hook examples.    

1.2 Singleton, Lightning Accounting, and Lock Mechanism

The singleton architecture and flash accounting aim to improve performance by reducing costs and ensuring efficiency. It introduces a new singleton contract, where all liquidity pools are stored in the same smart contract. This singleton design relies on a PoolManager to store and manage the state of all pools.

In the early versions of the Uniswap protocol, exchanging or adding liquidity involved direct token transfers. However, this is different in version 4, which introduces flash accounting and a lock mechanism.

The operating mode of the locking mechanism is as follows:

1. A certain locker contract requests a lock on PoolManager.

2. PoolManager adds the address of the locker contract to the lockData queue and calls its lockAcquired callback.

3. The locker contract executes its logic in the callback. During the execution process, the interaction between the locker contract and the pool may result in a non-zero currency increment. However, at the end of the execution, all increments must be settled to zero. In addition, if the lockData queue is not empty, only the last locker contract can perform the operation.

4. PoolManager checks the status of the lockData queue and currency increments. After verification, PoolManager will delete the locker contract. In summary, the locking mechanism prevents concurrent access and ensures that all transactions can be cleared. The locker contract applies for a lock in order, and then executes transactions through the lockAcquired callback. The corresponding Hook callback will be triggered before and after each pool operation. Finally, PoolManager will check the status.

This method means that the operation adjusts the internal net balance (i.e. delta) instead of executing an immediate transfer. Any modifications will be recorded in the pool's internal balance, and the actual transfer will take place at the end of the operation (i.e. lock). This process ensures that there are no unsettled tokens, thus maintaining the integrity of the funds.

Due to the existence of locking mechanism, all external accounts (EOA) cannot directly interact with PoolManager. Instead, any interaction must be done through a contract. This contract acts as an intermediate locker and requires a lock request before any pool operation can be performed.

There are mainly two types of contract interaction scenarios:

A locker contract comes from an official code repository or is deployed by a user. In this case, we can view the interaction as being routed through a router.

A certain locker contract is integrated with a Hook contract in the same contract, or controlled by a third party entity. In this case, we can consider the interaction as being carried out through the Hook. In this case, the Hook plays the role of the locker contract and is responsible for handling callbacks.

2 - Threat Model

Before discussing relevant security issues, we need to determine the threat model. We mainly consider the following two situations:

Threat Model I: Hook itself is benign, but there are vulnerabilities.

The threat model II: Hook itself is malicious.

In the following section, we will discuss potential security issues based on these two threat models.    

2.1 Threat Model I Security Issues

The threat model I focuses on vulnerabilities related to Hook itself. This threat model assumes that developers and their Hooks are not malicious. However, known vulnerabilities in smart contracts may also appear in Hooks. For example, if the Hook is implemented as an upgradable contract, it may encounter issues related to vulnerabilities such as the UUPSUpgradeable vulnerability in OpenZeppelin.

Given the above factors, we choose to focus on potential vulnerabilities unique to version 4.0. In Uniswap v4, a Hook is a smart contract that can execute custom logic before or after core pool operations (including initialization, position modification, swapping, and collecting). While Hooks are expected to implement standard interfaces, they also allow for custom logic. Therefore, our discussion will be limited to logic involving standard Hook interfaces. We will then attempt to identify potential sources of vulnerabilities, such as how Hooks may abuse these standard Hook functions.

Specifically, we will focus on the following two Hooks:

The first type of hook is to safeguard user funds. In this case, attackers may attack this hook to transfer funds, causing asset losses.

The second type of hook is to store critical state data that is dependent on the user or other protocols. In this case, attackers may attempt to change the critical state. This could potentially pose a risk when other users or protocols use incorrect state data.

Please note that hooks outside of these two scopes are not within the scope of our discussion. As there were no real use cases for hooks at the time of writing this article, we will be gathering information from the Awesome Uniswap v4 Hooks repository. After conducting a thorough investigation of the Awesome Uniswap v4 Hooks repository (commit hash 3a0a444922f26605ec27a41929f3ced924af6075), we discovered several serious vulnerabilities. These vulnerabilities mainly stem from the risk interaction between hooks, PoolManager, and external third parties, and can be divided into two categories: access control issues and input validation issues. Please see the table below for specific findings:

Overall, we have identified 22 relevant projects (excluding projects unrelated to Uniswap v4). Among these projects, we believe that 8 (36%) have vulnerabilities. Of these 8 vulnerable projects, 6 have access control issues and 2 are susceptible to untrusted external calls.

 2.1.1 Access Control Issues

In this discussion, we mainly focus on the potential issues caused by callback functions in v4, including 8 hook callbacks and lock callbacks. Of course, there are other situations that need to be verified, but these cases are design-specific and are not within the scope of our discussion.

These functions should only be called by PoolManager and cannot be called by other addresses (including EOA and contracts). For example, in the case of rewards distributed by the pool key, if the corresponding function can be called by any account, the reward may be mistakenly claimed.

Therefore, for hooks, establishing a strong access control mechanism is crucial, especially since they can be called by parties other than the pool itself. By strictly managing access permissions, a liquidity pool can significantly reduce the risk of unauthorized or malicious interactions with hooks.    

2.1.2 Input Validation Issues

In Uniswap v4, due to the existence of a locking mechanism, users must obtain a lock through the contract before executing any pool operations. This ensures that the current participating contract is the latest locker contract. However, there is still a possible attack scenario, which is an untrusted external call caused by improper input validation in some vulnerable Hook implementations:

Firstly, hook does not verify the funding pool that the user intends to interact with. This may be a malicious funding pool containing false tokens and executing harmful logic.

Secondly, some key hook functions allow for arbitrary external calls.

Untrusted external calls are extremely dangerous because they can lead to various types of attacks, including the well-known reentrancy attack. To attack these vulnerable hooks, attackers can register a malicious funding pool for their fake tokens and then call the hook to perform operations on the funding pool. When interacting with the funding pool, malicious token logic hijacks the control flow to perform malicious behavior.    

2.1.3 Preventive Measures for Threat Model I

In order to avoid security issues related to hooks, it is crucial to validate interactions by properly enforcing necessary access controls on sensitive external/public functions and validating input parameters. Additionally, reentrancy protection may help ensure that hooks are not executed repeatedly in the standard logic flow. By implementing appropriate security measures, a fund pool can reduce the risks associated with such threats.

2.2 Threat Model II Security Issues

In this threat model, we assume that the developers and their hooks are malicious. Given the broad scope of this issue, we only focus on security concerns related to version 4. Therefore, the key issue is whether the provided hooks can handle the encryption assets of user transfers or authorizations. As the method of accessing hooks determines the permissions that can be granted to hooks, we classify hooks into two categories based on this.

Managed Hooks: Hooks are not entry points. Users must interact with the hook through a router (possibly provided by Uniswap).

Standalone Hooks: Hooks are entry points that allow users to interact with them directly.

Figure 2: Example of Malicious Hook

2.2.1 Hosted Hook

In this case, the user's encrypted assets (including native tokens and other tokens) are transferred or authorized to the router. Due to the balance check performed by PoolManager, it is not easy for malicious hooks to directly steal these assets. However, there are still potential attack surfaces. For example, the fee management mechanism of version 4 may be manipulated by attackers through hooks.

2.2.2 Independent Hook When the Hook is used as an entry point, the situation becomes more complex.

In this case, because users can directly interact with the hook, the hook has gained more power. In theory, the hook can perform any desired operation through this interaction. In version 4, verifying the code logic is critical. The main issue is whether the code logic can be manipulated. If the hook is upgradable, this means that a seemingly secure hook may become malicious after an upgrade, posing significant risks. These risks include:

Upgradable proxy (can be directly attacked);

Contains self-destruct logic. May be vulnerable when selfdestruct and create2 are called together.

2.2.3 Preventive Measures for Threat Model II

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia