#9 1inch事件：从Calldata损坏到伪造结算：链上二进制漏洞利用持续

2025年3月5日，一个集成了1inch Fusion V1协议的第三方解析器合约遭受了协同攻击，导致总损失超过500万美元。根本原因是结算流程中的不安全 Calldata 重构，攻击者控制的交互长度触发了后缀组装期间的指针下溢，从而允许注入伪造的结算数据。一种错误的信任边界进一步促成了此次攻击：解析器合约仅凭 msg.sender 就隐式信任结算合约转发的所有 Calldata，导致攻击者控制的数据尽管通过了所有访问控制检查，却继承了结算级别的权限。

此次事件之所以成为2025年最复杂的 DeFi 攻击之一，并非因为它利用了新颖的金融原语，而是因为它利用了低级的 ABI 和内存布局假设，模糊了智能合约漏洞与经典二进制漏洞之间的界限。

背景

1inch Fusion V1 协议

1inch 是一个去中心化交易所（DEX）聚合器，它跨多个 DEX 获取流动性，为用户提供优化的交易执行。1inch Fusion 构建在聚合器的限价订单基础设施之上，引入了一种基于荷兰式拍卖的订单匹配模型，允许用户指定灵活的执行参数，例如价格范围和交易时间窗口。

在 Fusion 模型中，用户订单不直接由协议本身完成。相反，它们由称为解析器的专业参与者执行。解析器可以被视为特权的、已列入白名单的参与者：要获得资格，它们必须质押代币以获得足够的 Unicorn Power，这是一种经济性准入门槛机制。

在操作层面，解析器运行自己的链下基础设施，与 1inch 的后端 API 交互，以发现用户订单并确定何时以及是否完成它们。一旦解析器决定执行订单，它会通过一个专用账户向结算合约提交一个链上交易，由该合约执行实际的交易。（虽然 Fusion 涉及解析器之间竞争性的荷兰式拍卖，但此机制对于理解攻击并非必需，因此在此省略；为简化起见，我们假设解析器可以直接满足用户的订单条件。）

在执行交易时，解析器可以通过从外部市场获取流动性以提供优于用户最低要求的执行，或者直接使用自己的资产结算交易。在此过程中产生的任何盈余价值都将作为利润归于解析器。本文讨论的攻击针对的就是这样一个解析器合约。具体来说，是一个用于链上做市的合约，该合约持有资产并已授予结算合约批准，最终导致这些资产的损失。

订单处理和履行

1inch Fusion 中的订单执行由结算合约协调，并遵循一种由交互数据驱动的递归结算模型，而不是线性执行流程。

该过程始于解析器调用 settleOrders() 函数，传入编码第一个订单及其交互负载的 Calldata。结算合约不尝试一次性结算所有订单，而是通过重复调用内部 _settleOrder() 函数来增量处理它们。

对于每个订单，_settleOrder() 函数会在内存中重构一个对限价订单协议（AggregationRouterV5.fillOrderTo()）的调用。在此重构过程中，结算合约将额外的解析器相关上下文以动态后缀的形式附加到交互数据中。此后缀包含执行元数据，例如解析器身份和累计费用，并且被限价订单协议视为不透明。它会被原封不动地转发，稍后在交互回调期间由结算合约自身解码。

订单完成后，控制权通过 fillOrderInteraction() 函数返回到结算合约。根据交互数据，结算合约要么通过递归调用 _settleOrder() 函数并传入剩余的交互负载继续结算，要么进入最终确定阶段。在最终阶段，结算合约通过调用解析器合约的 resolveOrders() 函数将控制权转发给解析器合约，并传入累积的执行上下文。

此设计允许在单个交易中顺序结算多个订单，同时将特定于解析器的逻辑推迟到所有协议级别的执行步骤完成后。

漏洞分析

漏洞源于内部 _settleOrder() 函数中不安全的 Calldata 重构逻辑，特别是在将动态后缀附加到交互数据期间。

解析器合约受显式访问控制保护：它们要求调用来自结算合约，并且在解析期间提供的解析器地址与解析器合约本身匹配。这些检查假定通过结算过程传播的解析器身份已正确构造且保持不变。此假设取决于解析器相关数据在 Calldata 重构期间如何编码和附加的正确性。

在结算过程中，_settleOrder() 会在内存中重构 Calldata，并附加一个包含解析器特定执行上下文的动态后缀。此后缀不仅包括解析器地址，还包括解析器依赖于解释结算合法性的订单相关信息。后缀被写入计算为 ptr + interactionOffset + interactionLength 的内存位置，其中 interactionLength 直接从 Calldata 读取，作为完整的 32 字节值。

由于此偏移量计算是在没有边界检查的情况下执行的，因此攻击者可以控制 interactionLength 以触发算术溢出并操纵后缀在内存中的写入位置。通过这样做，攻击者可以替换预期的后缀，并使用伪造的后缀，提供任意解析器地址以及攻击者控制的订单上下文。

结果是，当结算流程稍后解码后缀时，它可能会将执行解释为源自合法解析器并涉及有效订单数据，尽管这两个假设都不成立。攻击者实际上能够通过冒充解析器来注入自己的订单后缀版本，用几个 wei 交换数百万。

攻击分析

以交易 ++0x74bc++ 为例。攻击始于创建五个有效订单，这些订单交换了微不足道的代币数量（几个 wei）以换取不成比例的大量输出金额。这些订单在语法上是有效的，并且通过了协议级别的检查。

然后，攻击者使用大片空字节填充订单 Calldata。此填充用作一个受控的内存区域，稍后由于后缀放置不正确而将被覆盖。

至关重要的是，攻击者为最终订单指定了一个无效的 interactionLength 值。该值选择为 0xffff…fe00，当解释为有符号整数时，对应于 -512。由于 interactionLength 被视为一个无符号 256 位值并直接用于指针算术，这会在计算后缀写入偏移量时导致算术溢出。