使用Crytic进行漏洞挖掘
Crytic是我们用于发现智能合约漏洞的GitHub应用程序：它无需人工干预即可检测安全问题，在您工作时提供持续保障，并在部署前保护您的代码库。
Crytic能够发现许多其他工具无法检测的漏洞，包括一些尚未广为人知的问题。目前，Crytic拥有90多个检测器，并且我们持续添加新的检查项并改进现有功能。它会在每次提交时运行这些漏洞和优化检测器，并评估您自己添加的自定义安全属性！
今天，我们将分享Crytic在主要项目中发现的十二个问题，包括一些高严重性的漏洞。
发现的问题汇总
以下是我们发现的问题。继续阅读了解具体发现位置：
- 未使用的返回值可能允许免费铸造代币
- registerVerificationKey总是返回空字节
- MerkleTree.treeHeight和MerkleTree.zero可以声明为常量
- 修饰器可能返回默认值
- 危险的严格相等可能使合约陷入陷阱
- ABI encodePacked碰撞
- 缺少继承容易出错
- Msg.value在fundWithAward中被使用两次
- 重入可能导致代币盗窃
- [待确认]
- [待确认]
- [待确认]
Ernst & Young Nightfall
Crytic在EY的Nightfall项目中发现了三个漏洞，包括一个可能允许任何人免费铸造代币的关键漏洞。
问题1：未使用的返回值可能允许免费铸造代币
描述 FTokenShield.mint不检查transferFrom的返回值。如果FTokenShield与在错误转账时不回退而只返回false的代币（例如BAT）一起使用，任何人都可以免费铸造承诺——攻击者可以免费铸造代币。
FTokenShield.burn中存在一个影响较小的类似问题：这里没有检查fToken.transfer。
建议 检查transferFrom和transfer的返回值。
Crytic报告
问题2：registerVerificationKey总是返回空字节
描述 FTokenShield.registerVerificationKey和NFTokenShield.registerVerificationKey返回一个空的bytes32。不清楚正确的返回值应该是什么。这可能导致第三方和合约出现意外行为。
建议 考虑返回一个值，或者从签名中移除返回值。
Crytic报告
问题3：MerkleTree.treeHeight和MerkleTree.zero可以声明为常量
描述 treeHeight和zero可以在MerkleTree.sol中声明为常量，以允许编译器优化此代码。
建议 永远不会改变的状态变量可以声明为常量以节省gas。
Crytic报告
DeFiStrategies
Crytic在DeFiStrategies中发现了一个不寻常的问题：修饰器中缺少占位符执行导致调用函数返回默认值。此外，Crytic还发现了一个与balanceOf调用返回值的严格相等相关的问题。
问题4：修饰器可能返回默认值
描述 SuperSaverZap.onlyInEmergency()和SuperSaverZap.stopInEmergency()修饰器在无效访问时不会回退。如果修饰器不执行或回退，函数的执行将返回默认值，这可能对调用者产生误导。
建议 在两个修饰器中将if()条件替换为require。
Crytic报告
问题5：危险的严格相等可能使合约陷入陷阱
描述 ERC20toUniPoolZapV1_General.addLiquidity对_UniSwapExchangeContractAddress余额使用了严格相等。这种行为可能允许攻击者通过向_UniSwapExchangeContractAddress发送代币来使合约陷入陷阱。
建议 在比较中将==改为<=。
Crytic报告
DOSNetwork
Crytic在DOSNetwork中发现了另一个不太为人所知的问题：如果使用多个动态参数调用abi.encodedPacked，它可能使用不同的参数返回相同的值。
问题6：ABI encodePacked碰撞
描述 DOSProxy使用带有两个连续字符串（dataSource和selector）的encodePacked Solidity函数：eth-contracts/contracts/DOSProxy.sol。
此模式容易发生碰撞，其中两个具有不同dataSource和selector的调用可能导致相同的queryId（更多信息请参阅Solidity文档）。
建议 不要在encodePacked中使用多个动态类型，并考虑首先使用keccak256对dataSource和selector进行哈希处理。
Crytic报告
ethereum-oasis/Baseline
Crytic在Baseline协议中发现了一个架构问题：实现接口的合约没有从该接口继承。
问题7：缺少继承容易出错
描述 Shield是ERC1820ImplementerInterface的一个实现，但它没有从该接口继承。这种行为容易出错，并可能阻止实现或接口正确更新。
建议 让Shield从ERC1820ImplementerInterface继承。
Crytic报告
EthKids
Crytic在EthKids中发现了另一个不寻常的问题：this.balance包括当前交易的数量（msg.value），这可能导致不正确的值计算。
问题8：Msg.value在fundWithAward中被使用两次
描述 fundWithAward中使用this.balance没有考虑已经由msg.value添加的值。因此，价格计算不正确。
fundWithAward通过使用msg.value调用calculateReward来计算代币数量：
|
|
calculateReward调用calculatePurchaseReturn，其中_reserveBalance是this.balance，_depositAmount是msg.value：
|
|
在calculatePurchaseReturn中，baseN通过将_depositAmount（msg.value）加到_reserveAmount（this.balance）来计算：
|
|
msg.value已经存在于this.balance中。例如，如果交易前this.balance是10 ether，msg.value是1 eth，交易期间this.balance将是11 ether。因此，msg.value被使用了两次，calculatePurchaseReturn的计算不正确。
建议 更改价格计算，使_reserveBalance不包括交易中发送的金额。
Crytic报告
HQ20
最后，Crytic在HQ20中发现了一个众所周知的问题：重入。这个重入问题很有趣，因为它发生在合约与具有回调功能的代币（如ERC777）一起使用时。这与最近的uniswap和lendf.me黑客攻击类似。
问题9：重入可能导致代币盗窃
描述 Classifieds在没有遵循检查-效果-交互模式的情况下对外部代币调用transferFrom。这导致重入，如果目标代币具有回调机制（例如ERC777代币），攻击者可以利用这一点。
有两个方法存在重入问题：
- Classifieds.cancelTrade(uint256)
- Classifieds.executeTrade(uint256)
建议 遵循检查-效果-交互模式。
Crytic报告
立即开始使用Crytic！
Crytic可以保护您的代码库免受关键漏洞的影响，并帮助您设计更安全的代码。还有什么不喜欢的呢？
立即注册Crytic。有问题吗？加入我们的Slack频道（#crytic）或在Twitter上关注@CryticCi。
如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News