智能合约有什么错误的算法

这篇博客文章是该系列文章的第二篇，将讲述一些简单的现实中智能合约安全性Bug，黑客们是如何利用它们造成系统的影响以及提供相应的修复代码。到目前为止，我们已经实现了3，000万美元的修复挽救，即直接归因于智能合约安全漏洞的2.5亿美元的损失。这次我们将分别存入两笔存款，分别为：57，896，044，618，658，097，711，785，492，504，343，953，926，634，992，332，820，282，019，728，792，003，956，564，819，968个代币，总计0个代币！

这篇博客文章将专门介绍算术运算的Bug（例如整数溢出）尽管智能合约提供了具有独特新颖性的执行环境，但这无疑不是一个新问题。算法的Bug几乎占据了SEI CERT Oracle Java编码标准中大部分的吸引力。其他开发语言也遭受完全相同的可怕情况，漏洞映射到几个常见的Bug中。智能合约主要面临与公共执行环境的安全，不可变更的性质，不同的利益相关者类别以及逻辑复杂性相关的独特挑战。

让我们看一下BeautyChainToken的合约代码，该代码可以在Etherscan上可以轻松找到。通过浏览代码可以发现在最顶部附近有一个名为SafeMath的库的实现，随后是一系列相互依存的合约。忽略周围其他的代码干扰，但请注意经常引用变量to，from，amount和balances以及称为transfer（）和approve（）的函数，这是一个不到300行的全功能代码。

让我们从第255行开始检查batchTransfer（）函数。它有两个参数-第一个参数（_receivers）是目标帐户地址的列表，第二个参数（_value）是要转移到每个目标帐户地址的代币数。第256行计算列表中接收方地址的数量，然后第257行可以计算从发送方帐户余额中提取的总金额。第259行确保发送方有足够的余额，然后第261将第257行向下调整之前的总金额。最后第262行开始循环，通过将每个接收者的余额向上调整_value来执行单独的转帐。

255 function batchTransfer（address［］ _receivers， uint256 _value） public whenNotPaused returns （bool） {

256 uint cnt = _receivers.length;

257 uint256 amount = uint256（cnt） * _value;

258 require（cnt 》 0 && cnt 《= 20）;

259 require（_value 》 0 && balances［msg.sender］ 》= amount）;

260

261 balances［msg.sender］ = balances［msg.sender］.sub（amount）;

262 for （uint i = 0; i 《 cnt; i++） {

263 balances［_receivers［i］］ = balances［_receivers［i］］.add（_value）;

264 Transfer（msg.sender， _receivers［i］， _value）;

265 }

266 return true;

267 }

Solidity中最常见的数据类型之一是unsign256位整数（uint256或uint），它可以表示0到2^256-1之间的任何值。如果合约代码执行一个普通的算术运算，得到的结果超出了这个范围，则结果会悄悄地被包装起来，合约也将会继续使用错误的数据，这是非常可怕的结果。出于这个原因，上面显示的合约特别是使用了前面看到的safemath库中的专用的.sub（）和.add（）函数（分别位于第261行和第263行）。如果遇到下溢或上溢，将编写这些通用函数来中止操作，这将阻止执行继续处理不良数据。您可能会问为什么第257行使用普通的‘*’而不是SafeMath中的.mul（）。

Bug！关于第257行，如果_value设置为2^255，然后由于在前一行计算出的cnt为2而加倍，则由于回绕（wrap-around）效应，结果将被存储进amount为0（而不是2^256）。这是我们旨在解决的确切错误-现在将继续处理错误数据，继续执行。要求的_value很大，但总计算amount为0！amount为0金额时余额检查将会被忽略第259行，并继续通过第261行上的进行余额调。然而在执行单个传输的循环利用了巨大的_value变量（不再引用数量变量）。这意味着循环将使两个目标余额分别增加2^255。累积增加！

发生了什么？攻击者调用了上面所示的batchTransfer（）函数，并为其提供了一个_receivers列表，该列表包含两个地址和一个_value参数设置为2^255。在Etherscan事务中可以清楚地看到这一点（单击“解码输入数据”）。如前所述，地址的cnt计算为2，因此乘以2^255的值将导致溢出到0。此错误数据将继续执行。通过各种参数检查，发件人的余额减少到0，最后将_value的两笔存款存入_receivers余额。顺便说一句，如果您还没有猜到的话，本帖子第一段中提到的大量数字恰好是2^255。大约0.02美元的真金白银来资助攻击交易，两笔大量的代币是凭空创建的，并存放到_receiver地址中。这导致了对该代币合约的信任丧失，从而彻底破坏了其价值。

让我们修复它。我们要做的就是用.mul（）替换第257行上的普通“ *”，如下所示。前缀为“ –”的行将从合约代码中删除，而前缀为“ +”的行将被添加。

- uint256 amount = uint256（cnt） * _value;

+ uint256 amount = uint256（cnt）.mul（_value）;

回想起来很简单吗？回看一下过去Bug，几乎所有安全Bug都变得非常明显，但二十多年来，开发人员一直在犯这些相同的错误。请注意，上述修复代码对于BeautyChainToken来说是没有意义的，因为智能合约的软件没有更新。一旦部署了智能合约，它们除原始代码之外就基本上不可更改且不可阻挡。因此，我们非常简单的解决方案（仅由几个字符组成）只能成为未来的一个教训，强调了“不要让算术结果出错，然后继续使用错误数据执行”。

没那么简单。代币是智能合约的一个用例之一，都是由顶级专家进行非常谨慎的开发。SafeMath库的存在表明这是一个已知的问题区域，但是我们上面看到的代码确实使用了SafeMath库。实际上，ERC-20代币标准本身就有几个已知的问题，这些问题仅能部分解决（最好）。