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

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

这篇博客文章是该系列文章的第二篇，将讲述一些简单的现实中智能合约安全性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个代币！

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

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 }

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）;

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