New multiOverflow Bug Identified in Multiple ERC20 Smart Contracts (CVE-2018-10706)

本文揭示了一种新型智能合约漏洞——multiOverflow,该漏洞存在于多个ERC20标准的智能合约中,允许攻击者通过整数溢出的方式无限生成代币。文章详细介绍了multiOverflow的工作原理,并以SocialChain发行的SCA代币为例,展示了如何发现并修复此类漏洞。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Our vulnerability-scanning system at PeckShield has so far discovered several dangerous smart contract vulnerabilities ( batchOverflowproxyOverflowtransferFlawownerAnyone). Some of them could be used by attackers to generate tokens out of nowhere while others can be used to steal tokens from legitimate holders. Today, we would like to report another vulnerability named multiOverflow that afflicts dozens of ERC20-based smart contracts. Our investigation shows that multiOverflow is another integer overflow bug which is similar tobatchOverflow but with its own characteristics.

Details

Integer overflow has been one of most common root causes of vulnerabilities in smart contracts. The multiOverflow bug also falls in this category.


                                                       Figure 1: The Vulnerable Function: transferMulti()

We show in Figure 1 the vulnerable function, i.e., transferMulti(). This function takes two parameters: an address array, _to, for naming receivers and an uint256 array, _value, for holding the amount transferring to each receiver. In line 250, we notice that amount is calculated by adding the product of _value and 10 to the power of decimal (set as 8 in the contract constructor). Obviously, this could be an integer overflow case because the sanity check in line 252 can be easily bypassed. To demonstrate, we craft a proof-of-concept with following parameters:

  1. _to
    • 0x93995bc9db9ae7af4f969400012c6fe94c93f761
    • 0x0c2a5f9a88bf2467f0b90e80e263e6c25daed62d
  2. _value
    • 0x15798ee2308c39df9fb841a566d74f87a7a9a7aeb02c2d2f8e0d1e768e
    • 0x15798ee2308c39df9fb841a566d74f87a7a9a7aeb02c2d2f8e0d1e768e

Since there’re two receivers, the loop in line 249-251 would be iterated twice. The execution proceeds as follows:

Iteration 1

amount += _value[0]*10**uint256(decimals);
==> amount += 0x15798ee2308c39df9fb841a566d74f87a7a9a7aeb02c2d2f8e0d1e768e * 100,000,000 (line 250)

Iteration 2

amount += _value[1]*10**uint256(decimals);
==> amount += 0x15798ee2308c39df9fb841a566d74f87a7a9a7aeb02c2d2f8e0d1e768e * 100,000,000 (line 250)

Now, amount is overflowed successfully to0x10000000000000000000000000000000000000000000000000000000004319c00 which equals to 0x4319c00 in uint256 format.

As long as the attacker has enough tokens, i.e., balanceOf[msg.sender] >= 0x4319c00, each receiver will receive a tremendous number of tokens —0x800000000000000000000000000000000000000000000000000000000218ce00.

The following figure demonstrates a successful attack which proves our theory:



Affected Tokens

The multiOverflow bug is of the same nature of other integer overflow vulnerabilities (e.g.,batchOverflow and proxyOverflow) and could cause similar damages. When analyzing deployed smart contracts, we find a few are affected. A particular example token is SCA, which is deployed by SocialChain (a blockchain startup focusing on entertainment and leisure industries). SCA is currently in the pre-sale stage, which means a successful multiOverflow attack can wreak havoc and cause serious financial loss to the company.

Upon the detection, we immediately contacted SocialChain and provided them with vulnerability details and necessary technical supports. The SCA team promptly responded to our notification and took actions to fix the problem actively. As of the time publishing this blog, a new smart contract with the multiOverflow bug fixed has been deployed while all addresses holding SCA tokens have been mapped to the new contract successfully. We applaud the team’s reaction and believe this is what a high-quality development team should behave!

Conclusion

As cryptocurrency is getting acceptable to the public, a popular way for entrepreneurs to raise funds is to issue tokens. Compare to prosperity of various tokens, security in blockchain is still at a primitive stage. As indicated in recent discovery of various smart contract vulnerabilities, very few (token-issuing) teams have taken the security into serious consideration before deploying their smart contracts.

We believe security is essential in any blockchain-based smart contracts and any token-related businesses (including ICOs and live DAPPs). Ealier vulnerabilities such as batchOverflow andproxyOverflow have demonstrated how devastating they could be once exploited by attackers. Regarding the SocialChain case, it’s fortunate that we are ahead by identifying and fixing the bug before any multiOverflow attack, thus successfully preventing possible damage or financial loss. But always keep in mind, attackers are out there, lurking in the shadows and seeking for another chance. This would be an endless arms race!

内容概要:本文档《团队协作避坑指南:用GitCode权限管理|10分钟配置精细化开发管控》主要介绍了如何利用GitCode进行权限管理,以实现团队协作中的高效、安全和精细化管控。首先,文档解释了GitCode权限管理的核心概念,包括不同级别的权限(如组织级、项目级、仓库级和分支级)及其作用范围和典型角色。接着,文档详细描述了10分钟快速配置权限的具体步骤,从创建组织到设置权限模板,再到创建项目组与成员。随后,文档深入探讨了精细权限控制方案,涵盖分支保护规则配置、文件级代码拥有者(CODEOWNERS)以及合并请求(MR)审批规则等内容。最后,文档提出了企业级管控策略,包括敏感操作限制、合规性审计方案和定期权限审查流程,并分享了某50人团队采用此方案后的显著成效,如权限配置时间减少85%,越权操作事故下降92%,代码审核效率提升60%。 适合人群:适用于有一定GitCode使用基础的技术负责人、项目经理和开发工程师等团队成员。 使用场景及目标:①帮助团队快速搭建和配置权限管理体系;②确保代码库的安全性和稳定性;③提高团队协作效率,降低越权操作风险;④为新入职员工提供标准化的权限配置流程。 阅读建议:本指南不仅提供了详细的配置步骤,还强调了权限管理的最佳实践和持续优化建议。读者在学习过程中应结合实际应用场景,灵活应用所学内容,并定期审查和调整权限设置,以适应团队发展的需要。
### 关于 MySQL 输入验证错误漏洞 CVE-2022-21454 #### 漏洞详情 CVE-2022-21454 是指在 MySQL 数据库管理系统中的输入验证存在缺陷。当处理特定类型的 SQL 查询时,如果用户提供了恶意构造的数据作为参数,则可能导致服务器崩溃或执行任意代码。此问题影响多个版本的 MySQL 和 MariaDB,在某些情况下可能被远程攻击者利用来实施拒绝服务(DoS)攻击或其他更严重的后果。 具体来说,该漏洞存在于解析 JSON 文档的过程中[^3]。由于未能正确地检查传入数据的有效性,使得未经适当清理的内容能够绕过正常的防护机制并触发内部逻辑错误。这不仅限于直接通过应用程序接口提交的信息;还包括任何可以间接传递给数据库引擎的地方,比如存储过程调用、事件调度器任务等。 #### 影响范围 受影响的产品及其版本如下: - Oracle MySQL Server 8.0.27 及之前版本 - Percona Server for MySQL 8.0.x 系列 - MariaDB 10.6.x, 10.5.x, 10.4.x 各分支 对于企业级部署而言,及时评估当前使用的软件是否处于风险之中至关重要。建议管理员查阅官方发布的安全公告以获取最准确的影响列表[^3]。 #### 解决方法与缓解措施 针对这一安全隐患,厂商已经发布了补丁程序更新。为了防止潜在威胁的发生,强烈推荐采取以下行动: 1. **立即升级至最新稳定版**:安装由供应商提供的修复包是最有效的解决办法。例如,Oracle 已经在其后续发行版中解决了这个问题,如 MySQL 8.0.28 或更高版本。 2. **应用临时修补脚本**:如果无法马上进行全面迁移,可以通过修改配置文件的方式减少暴露面。设置严格的连接限制和资源控制策略有助于降低危害程度。此外,还可以考虑启用只读模式或将敏感操作迁移到隔离环境中运行。 3. **加强审计日志记录强度**:确保启用了详细的查询历史追踪功能,并定期审查异常活动迹象。这样可以在早期发现可疑行为并作出响应。 4. **强化身份认证体系**:采用多因素验证(MFA),并对不同级别的权限进行精细化管理。最小化特权原则同样适用于数据库账户分配场景下,即授予刚好足够的访问权利完成必要的工作即可。 ```sql ALTER USER 'your_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'StrongPassword!'; FLUSH PRIVILEGES; ``` 以上SQL语句用于更改指定用户的密码为强随机字符串形式,从而提高安全性[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值