引介 | EIP-3074隐含合约调用安全漏洞，应采取什么机制进行防范？

原标题：《引介 | 对 EIP-3074 的批评以及一种简单的替代》

对于开发者来说，AUTH/AUTHCALL?机制非常具有吸引力。它可以让人们创建调用者来实现不同的批量处理策略（例如，支持多个 nonce 来实现更好的并行性）、gas 抽象模型和复杂的账户抽象方法等。

这种灵活性源于这一机制赋予了开发者极大的自由。AUTH/AUTHCALL?机制不要求开发者遵循特定的模式，而是要求用户签署一个?commit?哈希值（commit 内容将由调用者来解析），让开发者基于?commit?自行设置限制。

然而，这种灵活性是以牺牲安全性为代价的。在本文中，我想要介绍一种更简单的替代方案。这个方案具备?AUTH/AUTHCALL?机制的绝大多数优点，但是风险远低于后者。

为什么签署一个 AUTH?commit?所带来的风险高于签署一个与存在漏洞/恶意合约相关的事务？

用户在签署与合约相关的事务时，所承担的风险是已知的，即，可能会损失在该合约控制范围内的资产。比方说，用户给一个 ERC 20 合约签署了批准事务，授权恶意的 DEX 合约。这个恶意 DEX 合约就可以提走用户在 ERC 20 合约中的全部余额。但是，它无法从该用户的其它 ERC 20 合约中提走代币，除非得到该用户的批准。它也不能代表用户进行其它操作，因为这也需要专门获得用户的批准。

相较之下，EIP 3074 不仅要求用户签署 “空白支票”，而且假设调用者是诚实且没有漏洞的。一个恶意/存在漏洞的调用者可以代表用户执行任何操作?—— 访问用户持有的资产，代表用户进行投票，控制用户所有的合约等。

更糟糕的是，调用者随时都可以作恶，因为 nonce 实现是由调用者控制的。存在漏洞/恶意的 nonce 逻辑实现可以重放用户过去的事务。如果?commit?验证的其它部分的逻辑也存在漏洞，调用者就可以利用这个 nonce 逻辑实现来代表用户执行任何操作。即使漏洞被发现，用户也无法撤回空白支票。这个外部账户（EOA）已经被永久入侵了。

编写一个正确的调用者程序很难，而且我们几乎可以肯定，调用者会不定期出现错误，从?EIP 3074 最后列出的调用者应该警惕的检查/漏洞/情况非详尽清单中可见一斑。这份清单势必会变得越来越长，很可能伴随着痛苦的发现过程。

此外，恶意参与者可以编写一个看似无害的调用者程序，但是故意留下一个细微的漏洞，等到大量外部账户授权该调用者之后才会被攻击者利用。

如果攻击者没有直接或立即利用这个漏洞从用户那里窃取资金，这个漏洞可能很长时间都不会被发现。

EveSwap 用户不太可能注意到这个过程，因为交易总是成功的，但是最终会给 AliceSwap 带来毁灭性的打击。

EIP 3074 合理地建议?commit?应该包含?chainid。但是，这是由调用者，而非协议执行的。在另一条链上有着相同地址的调用者可能会跳过该检查（或与此相关的检查）。

用户从未在以太坊上交易过，运行在 BobSpongeChain 上的调用者程序又经过了严格的安全审查。尽管如此，用户还是丢失了全部资产。

以太坊通过 EIP 155 的重放保护来防范这种情况。AUTHCALL 没有重放保护。由于所有?commit?检查都交给调用者完成，我们失去了以太坊提供的一切交易保护。攻击是在所难免的，因为保护措施很随意。如果要接受EIP 3074，AUTH 消息必须明确包含?chainid，而非将其作为?commit?的一部分。

我的提议是实现一个更明确的机制，在协议层面强制规定?commit?的含义。commit 结构将是类型化的（如 EIP 712 所述），钱包会以用户可读的形式将 commit 呈现出来。用户可以确切地知道事务是什么样子的，并确信这个事务不会在任何链上重放，无需依赖于调用者程序开发者的品行和能力。

一个可能的实现：

AUTH?将使用包含授权调用列表的类型化结构代替?commit?哈希值。每个调用都将指定 {nonce,to,gas,calldata,value,chainid}。签名将被验证，整个授权调用列表将保存为?authorized_transactions?而非?authorized?地址变量。

AUTHCALL?将得到一个新的参数?index，该参数指向最后一个?AUTH?创建的列表中的地址。

用户地址的 nonce 将随?AUTHCALL?递增。nonce 并非由调用者存储，而是实际的账户 nonce。

利：

弊：

不同的实现可能支持不同的 nonce 方案。但是，无论我们使用什么机制，该机制必须由协议而非调用者执行。

无论如何都应该避免让复杂调用者执行大量用户调用。复杂操作应该作为普通的智能合约实现，而非尝试实现使用多个外部账户调用的算法。

还有一个选择是完全避免 AUTH 机制，并通过?vbuterin?建议的另一种交易池来解决账户抽象和批量处理问题。

利：

弊：

除非要求在不迁移的情况下支持已有的外部账户，否则这个选择看起来更安全。

（完）

（文内有许多超链接，可点击左下 ”阅读原文“ 从 EthFans 网站上获取）

原文链接:

https://blog.mycrypto.com/eip-3074/

作者: Maarten Zuidhoorn

翻译&校对:?闵敏 & 阿剑

—-

编译者/作者：以太坊爱好者

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。