Uniswap v4 Hook机制的双面性：创新与潜在风险并存

Uniswap v4即将推出,这次升级可谓雄心勃勃。新版本将引入多项全新功能,包括支持每个交易对无限数量的流动性池和动态费用、单例设计、闪电记账、Hook机制,以及ERC1155代币标准支持。利用瞬态存储技术,Uniswap v4预计将在以太坊坎昆升级后发布。

在众多创新中,Hook机制因其强大潜力备受关注。该机制允许在流动性池生命周期的特定节点执行自定义代码,大大增强了池子的可扩展性和灵活性。

然而,Hook机制也可能是把双刃剑。尽管功能强大且灵活,但安全使用Hook同样面临不小挑战。Hook的复杂性不可避免地带来了新的潜在攻击向量。因此,有必要系统介绍与Hook机制相关的安全问题与潜在风险,以推动社区的安全发展,这些见解将有助于构建更安全的Uniswap v4 Hook。

本文将介绍Uniswap v4中Hook机制的相关概念,并概述其存在的安全风险。

Uniswap V4的机制

在深入探讨之前,我们需要对Uniswap v4的机制有基本了解。根据官方公告和白皮书,Hook、单例架构和闪电记账是实现自定义流动性池和跨多个池子高效路由的三个重要功能。

1.1 Hook

Hook是指在流动性资金池生命周期不同阶段运行的合约,Uniswap团队希望通过引入Hook使任何人都能做出权衡决策。这种方式可以实现原生支持动态费用、添加链上限价单,或者通过时间加权平均做市商(TWAMM)分散大订单。

目前有八个Hook回调,分为四组(每组包含一对回调):

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

Uniswap团队提供了一些示例(如TWAMM Hook)介绍操作方法,社区参与者也做出了一些贡献。官方文档还链接到了Awesome Uniswap v4 Hooks仓库,该仓库收集了更多Hook示例。

1.2 单例、闪电记账和锁机制

单例架构和闪电记账旨在通过降低成本和确保效率来提高性能。它引入了一种新的singleton合约,即所有流动性池都保存在同一个智能合约中。这个单例设计依赖PoolManager来存储和管理所有池子的状态。

Uniswap 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本身就是恶意的。

接下来将根据这两种威胁模型讨论潜在安全问题。

2.1 威胁模型I中的安全问题

威胁模型I关注与Hook本身相关的漏洞。这个威胁模型假设开发者及其Hook是无恶意的。然而,智能合约现有的已知漏洞也可能出现在Hook中。例如,如果Hook是作为可升级合约实现的,那么它可能会遇到类似于OpenZeppelin的UUPSUpgradeable漏洞的相关问题。

鉴于以上因素,我们选择聚焦于v4版本特有的潜在漏洞。在Uniswap v4中,Hook是能够在核心池操作(包括初始化、修改位置、交换和收集)之前或之后执行自定义逻辑的智能合约。虽然Hook预计将实现标准接口,但也允许包含自定义逻辑。因此,我们的讨论范围将限制在涉及标准Hook接口的逻辑。然后,我们将尝试找出可能的漏洞来源,例如,Hook可能如何滥用这些标准Hook函数。

具体来说,我们将关注以下两种Hook:

• 第一种hook,保管用户资金。在这种情况下,攻击者可能会攻击这个hook来转移资金,造成资产损失。

• 第二种hook,存储用户或其他协议依赖的关键状态数据。在这种情况下,攻击者可能会试图改变关键状态。当其他用户或协议使用错误状态时,可能会带来潜在风险。

请注意,这两种范围之外的hook不在我们的讨论范围内。

在对Awesome Uniswap v4 Hooks仓库进行深入研究后,我们发现了几个严重漏洞。这些漏洞主要源于hook、PoolManager以及外部第三方之间的风险交互,主要可以分为两类:访问控制问题和输入验证问题。

总的来说,我们发现了22个相关项目(排除与Uniswap v4无关的项目)。在这些项目中,我们认为有8个(36%)项目存在漏洞。在这8个有漏洞的项目中,6个存在访问控制问题,2个容易受到不受信任的外部调用。

2.1.1 访问控制问题

在这部分讨论中,我们主要关注v4中的回调函数可能导致的问题,包括8个hook回调和lock回调。当然,还有其他情况需要验证,但这些情况因设计而异,暂不在我们的讨论范围之内。

这些函数应该只能被PoolManager调用,不能被其他地址(包括EOA和合约)调用。例如,在奖励由资金池密钥分发的情况下,如果相应的函数可以由任意账户调用,那么奖励可能会被错误地领取。

因此,对于hook来说,建立强大的访问控制机制是至关重要的,尤其是它们可以被除了池子本身之外的其他方调用。通过严格管理访问权限,流动性池可以显著降低与hook未授权交互或恶意交互的风险。

2.1.2 输入验证问题

在Uniswap v4中,由于存在锁机制,用户在执行任何资金池操作之前必须通过合约获得一个lock。这确保了当前参与交互的合约是最新的locker合约。

尽管如此,仍然存在一个可能的攻击场景,即由于在一些易受攻击的Hook实现中输入验证不当而导致的不受信任的外部调用:

• 首先,hook并未验证用户打算交互的资金池。这可能是一个含有虚假代币并执行有害逻辑的恶意资金池。

• 其次,一些关键的hook函数允许任意的外部调用。

不受信任的外部调用极其危险,因为它可能导致各种类型的攻击,包括我们熟知的重入攻击。

为了攻击这些易受攻击的hook,攻击者可以为自己的虚假代币注册一个恶意资金池,然后调用hook在资金池执行操作。在与资金池交互时,恶意代币逻辑劫持控制流以便进行不良行为。

2.1.3 针对威胁模型I的防范措施

为了规避与hook相关的此类安全问题,通过适当执行对敏感的外部/公共函数的必要访问控制,并对输入参数进行验证,从而对交互进行验证是至关重要的。此外,重入保护可能有助于确保hook不会在标准逻辑流程中被重复执行。通过实施适当的安全防护措施,资金池可以降低与此类威胁相关的风险。

2.2 威胁模型II中的安全问题

在这个威胁模型中,我们假设开发者及其hook是恶意的。鉴于涉及范围很广,我们仅关注与v4版本相关的安全问题。因此,关键在于提供的hook是否能够处理用户转账或授权的加密资产。

由于访问hook的方法决定了可能赋予hook的权限,我们据此将hook分为两类:

• 托管型Hook(Managed Hooks):hook不是入口点。用户必须通过路由器(可能由Uniswap提供)与hook进行交互。

• 独立型Hook(Standalone Hooks):hook是入口点,允许用户直接与之交互。

2.2.1 托管型Hook

在这种情况下,用户的加密资产(包括原生代币和其他代币)被转账或授权给router。由于PoolManager执行了余额检查,恶意hook不容易直接窃取这些资产。然而,仍然存在潜在的攻击面。例如,v4版本的费用管理机制可能会被攻击者通过hook进行操纵。

2.2.2 独立型Hook

当Hook被用作入口点时,情况就更加复杂。在这种情况下,由于用户可以直接与hook进行交互,hook获得了更多的权力。理论上,hook可以通过这种交互执行想要的任何操作。

在v4版本中,代码逻辑的验证是非常关键的。主要问题在于是否可以操纵代码逻辑。如果hook是可升级的,这意味着一个看似安全的hook可能会在升级之后成为恶意的,从而构成重大风险。这些风险包括:

• 可升级的代理(可以被直接攻击);

• 带有自毁逻辑。在联合调用selfdestruct和create2的情况下可能被攻击。

2.2.3 针对威胁模型II的防范措施

至关重要的一点在于评估hook是否是恶意的。具体来说,对于托管型hook,我们应该关注费用管理的行为;而对于独立型hook,主要的关注点在于它们是否可升级。

结论

本文首先简要概述了与Uniswap v4的Hook安全问题相关的核心机制。随后,我们提出了两种威胁模型并简要概述了相关的安全风险。

在后续文章中,我们将对每种威胁模型下的安全问题进行深入分析。