针对区块链安全问题，成都安联技术团队每周都会对智能合约的安全漏洞进行分析和连载，希望能够帮助程序员写出更加安全牢固的合约，防患于未然。

举止得体，举止得体，羞惭谄媚。《3354》前情提要韩愈

上一次说

区块链游戏如画，

安全防护不规划，

一抹夕阳挂在西边。

在上一期的区块链游戏漏洞总结分析中，我们将当前游戏契约的问题与前几期的漏洞连载分析联系起来，发现游戏契约的漏洞很大一部分是重复之前的令牌契约重大错误。裹着亮色外衣的游戏合约，不仅吸引更多的眼球，还需要更加重视安全问题，才能获得更长远的发展。

本期第七回

，局部变量猝不及防，意外变量覆盖最近新闻中的“占座”事件，在社会上引起强烈反响。一个合适的座位环境，在一些人不守规则的时候，造成了买票的乘客没有座位，车厢里的秩序混乱。

成都联安科技的朋友们在办公室就此事件发表了自己的看法，进行了激烈的讨论，一致反对这种不合理的行为。但是，除了讨论之外，我还认为，没有坐对座位导致的混乱问题，其实在智能合约漏洞问题上也有类似的情况。

基础知识

我们都知道，说到存储，变量在存储的时候都是分配了一个存储位置的。这个位置可以理解为乘车时的座位。

智能契约语言Solidity中的存储和内存是两个不同的概念。存储变量是指永久存储在区块链中的变量。内存变量是临时的，它们将在外部调用后被删除。

但是Solidity目前默认将复杂数据类型，如array(数组)和struct(结构)作为函数中的局部变量存储在存储中。

另外，实性对于状态变量，存储顺序一般是按照它们出现的顺序排列的。这些状态变量的位置相当于它们的座位。

有什么问题

Solidity与传统语言明显不同，它允许你定义一个对存储的引用。默认情况下，未初始化的外部指针(引用)将指向起始地址。如果它们没有被初始化，它们将被直接赋值，0地址的状态变量将被覆盖。

以坐火车为例。第一批乘客上车的时候没有安排相应的座位号，大家就蓑衣网小编2022按照上车顺序从前到后。到了新的目的地，第二批乘客上车没有分配座位号，就占了剩下的座位，想从前面坐到后面。第一批乘客原本坐在座位上，现在被“座霸”直接赶走，没地方坐了。

合同中“坐大欺小”的例子

开发中的缺手

成都安联技术团队翻开之前的漏洞案例书，发现这个漏洞原本体现在开发人员疏忽留下的、被攻击者利用的漏洞中，比如安全公司发现的与BancorLender相关的指针。

如图所示，状态变量agreements最初在第一个黄色框中声明，并进入起始位置槽000。

第二个黄框是试图在函数offerToLend()中声明一个新的局部变量agreement，但是还没有初始化，所以起始位置slot 000将被新的局部变量agreement占用。更具体地说，粉色线的最后三个赋值操作将覆盖从槽000到槽003的原始值。

最后导致代码逻辑紊乱，功能无法正常实现[1]。

另外蓑衣网小编2022，联系到我们上一期提到的游戏契约，这个漏洞也出现在了游戏契约中，不过是以蜜罐的形式出现的，我们之前已经提到过。这是一个故意的企图，放置明显的缺陷，使了解一点技术的玩家认为他们可以利用它，但实际上这是一个不公平的利润操作空间 所以我们把这种情况归为这种漏洞的第二种具体情况。

该案来自一个名为OpenAddressLottery的赌博合同。

这部分代码中的“s”是声明的，但并没有相应初始化，所以实际上后续的赋值操作会覆盖原地址中的重要值。

会替换哪些值？我们来看看谁“坐”在初始存储地址上：

所谓可预测的最终答案LuckyNumber所占据的初始位置，所以实际上会被tx.gasprice*7覆盖，而addresshowner会被msg.sender代替，但这两个值实际上是一样的。

因为luckyNumberOfAddress的结果是以模8(二进制)的形式计算的，而tx.gasprice*7的真实结果被覆盖后肯定会大于7，所以玩家是绝对不可能赢的[2]。

我们还要注意一点。在第一部蓑衣网小编2022分代码中，require(msg.send==owner)意味着只有契约所有者才能调用这个可以覆盖原始值的函数，所以契约的蜜罐意图非常明显。

最后的结果也符合我们的推断：

契约创造者在转移了所有参与者的资金后，开始了自我毁灭，跑路了。

呈现总结及修复建议

总结以上具体案例，我们可以说：

未初始化的内存局部变量可以指向契约中的状态变量，从而产生有意(即开发者故意放在那里攻击)或无意的漏洞。

我们将默认存储在存储中的一些典型变量分为struct和Array，展示一个错误示例[3]。

典型结构错误示例：

When _ name=" 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000时。开发者不能忽视这个警告。在声明变量的时候，要对这些本地内存变量进行初始化，或者根据它们的用途，把它们安排在临时内存空间上，避免安全漏洞。

良好的秩序，良好的心态

本期介绍的漏洞是由Solidity语言的默认存储规则和引用未初始化变量的特殊性造成的。在传统语言中，这种情况会在编译器中报错，无法通过。目前的Solidity版本(0.4.24)并没有同样严格的禁止，只是在编译器中给出了一个告警。

因此，成都联安科技团队在此再次强调智能合约的开发和使用：

遵守合约开发规范，精心做好安全防护准备，是我们多次提到的合约开发精神。在应用区块链这一新兴技术时，只有遵守规范，全面规划，才能更好地帮助新兴技术稳步发展。对于意图欺骗公众的投机性合同，当发现破绽时，一定要提防合同订立者的蜜罐手段，时刻保持警惕，以免上当受骗。

目前的区块链是一个不成熟的行业，需要发展。在追逐机会的同时，需要冷静思考，对成功有一个平和的心态。请给变量分配位置，同时，调整心态。

好了，本期的漏洞分析到此结束。见下回：

转移过程复杂

安全要一个一个处理

引用：

[1]:坚固性缺陷容易使契约状态失控

3333

[2]:这个蜜罐是怎么工作的？

https://www . Reddit . com/r/eth dev/comments/7wp 363/how _ this _ honey pot _ work _ it _ like _ a/？

[3]:带有不受控制且未初始化的构造函数的存储指针

https://eth fans . org/posts/comprehensive-list-of-common-attack-and-defense-part-7？

相关阅读：

链安全团队漏洞分析连载no . 1-溢出漏洞

链安全团队漏洞分析连载No.2？——?拒绝服务漏洞

链安全团队漏洞分析连载第3期？——?竞争条件漏洞

链安全团队漏洞分析连载No.4？——?底层函数误用漏洞

链安全团队漏洞分析连载第5期？一个接一个？验证错误

链安全团队漏洞分析连载6-游戏契约漏洞综合汇总