基于以太坊的开放协议0x项目发生了严重的安全漏洞

[导读] 去中心化交易所协议 0x 项目方称其发现严重安全漏洞。PeckShield 安全人员跟进分析发现，0x Exchange 合约在校验订单签名时存在缺陷，导致攻击者可以进行恶意挂单，进而将用户的数

去中心化交易所协议 0x 项目方称其发现严重安全漏洞。PeckShield 安全人员跟进分析发现，0x Exchange 合约在校验订单签名时存在缺陷，导致攻击者可以进行恶意挂单，进而将用户的数字资产低价卖出，扰乱正常的交易秩序。所幸项目方及时发现并修复问题，截至目前，尚未有真实攻击发生，并没有产生数字资产损失。

背景

北京时间2019年07月13日，去中心化交易所0x协议项目方称其发现严重安全漏洞，并紧急关闭了 0x Exchange v2.0 合约，随后部署了修复后的合约。受此影响，基于 0x 协议的交易所及钱包，包括 Radar Relay，Tokenlon， Star Bit 等紧急暂停了相关交易服务。

PeckShield 安全人员跟进分析发现，0x Exchange 合约在校验订单签名时存在缺陷，导致攻击者可以进行恶意挂单，进而将用户的数字资产低价卖出，扰乱正常的交易秩序。

0x 协议简介

0x 协议是一个基于以太坊的开放协议，实现链上资产的点对点交易。它期望在以太坊上创建一种标准协议，使得任何人能够基于此协议运行去中心化交易所，实现以太坊上的代币之间的交易。0x 协议上的交易特点是链下订单撮合，链上结算，其中为用户交易提供订单服务的参与者称为中继者。0x 项目发行了自己的代币 ZRX，一方面作为去中心化治理投票权的证明，同时也被作为交易服务费，用于建立在 0x 协议之上的中继者提供服务的收益。

0x 协议受到不少去中心化交易所和钱包的青睐，从 Etherscan 的 DEX 过去七天交易份额的饼图中能看到，排名靠前的 Radar Relay 和 Tokenlon 都是基于 0x 协议：

另外，从 DAppTotal 的 DEX 24小时交易额排名中也能看到它们的排名：

由于 Ethereum 平台上大量的 DEX 都使用了 0x 协议，而作为最根本的 Token Tranfer 主合约出问题，这对于整个 DEX 领域来说，都是比较重大的事件。

漏洞原理分析

本次漏洞共涉及 isValidWalletSignature（）和 isValidValidatorSignature（）两个相似的漏洞，由于两者出问题的代码是相似的，本文只以前者为例说明。

isValidWalletSignature（bytes32， address， bytes）函数用于验证给定的 Wallet 合约所定义的签名信息与给定的签名是否一致，用于确保 Order 是由正确的 Maker/Taker 执行的交易。但是 0x Exchange 合约在验证的过程中，存在着比较严重的问题：

上图是这一函数的全部逻辑，分为两部分：

1. 组装签名具体字段为 ABI 编码格式；

2. 根据组装的 ABI 编码内容计算签名值正确性。

其中，第 2 步的逻辑，在 0x v2 合约代码中是用汇编实现的：

1. 引入 cdStart 指针，指向 calldata 中对应的位置；

2. 对 WalletAddress 调用 staticcall（） OpCode 计算签名正确性，

注意观察代码，其中的 input 和 output 都为 cdStart 这一指针，即复用 input/output 的内存；

3. 检验步骤 2.2 中的结果是否正确。

WalletAddress 为合约的前提下，这样子的流程没有问题。先来看下 EVM 中合约的执行流程是怎样的，PeckShield 安全人员查阅 EVM 源码的时候发现：

当被调用的合约（即这里的 WalletAddress ）没有 code，也就是 EOA 账号的情况下，什么都没有的执行，直接返回。因此，对应到 isValidWalletSignature（bytes32， address， bytes）函数来说，其中的 cdStart 所对应的内存内容在调用 staTIccall（）前后并没有变化，而后面在判断签名是否正确的 isValid 取值的时候，也就取到了错误的值。

用户通过 fillOrder（Order， uint256， bytes）函数完成 Token 买卖，PeckShield 安全人员发现，这一函数的三个参数可以由用户自由配置：

分别为：

1. 代表订单信息的 Order 类型；

2. 用户为此订单付出的 Token 数量；

3. Order 对应的签名信息 signature

其中比较关键的是 Order 及对应的 signature 信息的一致性正是通过上面的 isValidWalletSignature（）类函数校验，因此，当攻击者精心构造 signature 为 SignatureTypeWallet 时，可『跳过』签名合法性检查，从而使得用户在不经意之间被恶意挂单（甚至是低价挂单），从而被攻击者顺利吃单，由于这一订单信息是由攻击者直接传入合约的，因此这一订单信息在线下的中继者也无法查询。

漏洞影响分析

基于上述分析发现，曾在 0x 协议 Exchange 上做过授权转账的普通用户帐号都将受到影响：

攻击者可伪造用户挂单，低价获得用户代币。

鉴于此安全漏洞的危害性，PeckShield 安全人员发现 0x 项目方在漏洞被发现的时候先紧急关闭了 0x Exchange v2.0 合约的 Token transfer 功能，将所有的 ERC20、ERC721、以及 MulTIAsset 的 Transfer 功能全部下线；随后部署了修复后的合约，同时告知用户及使用了 0x Exchange 的所有 DEX 及 Relayer，相关的迁移升级工作正在进行中。受此影响，基于 0x 协议的交易所及钱包，包括 Radar Relay， Tokenlon， Star Bit 等紧急暂停了交易服务。

PeckShield 安全人员通过漏洞特性分析链上数据发现，从 0x Exchange 2018-09 上线至今，并没有因此安全漏洞造成的用户直接资产损失。

对于使用了 0x 的 DEX 及钱包来说，当前的阶段需要暂停交易服务，如无法暂停交易服务的话，可将对应的 0x Exchange 合约地址变更为当前已经修复的合约地址。

结语

0x 协议本次出现漏洞的合约代码，主要是内联汇编代码编写签名验证功能出现的问题，直接编写汇编代码虽然在编译器无法优化合约代码的情况下非常有用，可控性更强且能提高执行效率，减少 Gas 消耗，但是编写 Solidity 汇编代码需要对 EVM 运行机制有非常熟悉的理解，不然 EVM 的某些特性可能导致编写的合约无法正常运行，同时也缺少了 Solidity 提供的多种安全机制。

PeckShield 安全人员在此提醒广大开发者及时排查合约的相关代码，避免类似问题可能造成的安全风险，对于 DEX 等 DeFi 类项目，项目方在上线前需要找有资质的安全公司审计安全风险。