7 月 13 日，去中心化交易所协议 0x 宣布发现安全漏洞，0x Exchange v2.0 合约暂时关闭，修复的交易合约计划晚些时候部署到以太坊主网。0x 称该漏洞允许攻击者使用无效签名填写某些订单，但不影响 ZRX 代币合约，并表示目前没有人利用此漏洞，也没有用户资金丢失。

链闻整合了国内两家区块链安全机构慢雾与 PeckShield 对该漏洞的分析，前者较为简练，后者较为详尽。

0x 合约中设置了 isValidWalletSignature 和 isValidValidatorSignature 函数对多签合约账号（Wallet Contract）及验证人合约账号（Validator Contract）进行签名有效性验证。

在这两个函数实现中因为没有对 address 进行校验，导致非合约账号（EOA）可以构造特殊数据，来通过这两个函数进行签名有效性验证，并结合函数逻辑缺陷，导致可伪造签名数据。

1、在 EVM 中 call 调用一个非合约账号（EOA）不会有任何返回值，也不会发生 revert； 2、在 EVM 中获取 call 调用的返回值时，如果 input output 使用同一指针，并且 call 调用没有返回值，则 input 数据不会被重置。

漏洞发现者：samczsun 博客披露细节：The 0x vulnerability, explained 0x 官方博客说明：https://blog.0xproject/shut-down-of-0x-exchange-v2-0-contract-and-migration-to-patched-version-6185097a1f39

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

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

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 合约在验证的过程中，存在着比较严重的问题：

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

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

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

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

引入 指针，指向 中对应的位置；

对WalletAddress调用 OpCode 计算签名正确性，注意观察代码，其中的 input 和 output 都为?这一指针，即复用 input/output 的内存；

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

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

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

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

分别为：

代表订单信息的 类型；

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

对应的签名信息 signature

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

基于上述分析发现，曾在 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 提供的多种安全机制。

来源链接：mp.weixin.qq