You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most of the injected bug patterns for reentrancy are not exploitable, or are even effectively dead code. This seems like a major drawback of this dataset when trying to evaluate reentrancy detection tools: the more precise a tool becomes, the worse it will perform on this dataset. In my opinion this is quite misleading.
The following pattern is injected into many of the contracts in the reentrancy category:
mapping(address=>uint) balances_re_ent17;
function withdrawFunds_re_ent17 (uint256_weiToWithdraw) public {
require(balances_re_ent17[msg.sender] >= _weiToWithdraw);
// limit the withdrawal
(boolsuccess,)=msg.sender.call.value(_weiToWithdraw)("");
require(success); //bug
balances_re_ent17[msg.sender] -= _weiToWithdraw;
}
Now here balances_re_ent17 is 0 initialized as all datatypes in Solidity/Ethereum. There is no way to change the values in balances_re_ent17. As such, the only valid call that does pass the require statement in the beginning of withdrawFunds_re_ent17 is to pass _weiToWithdraw == 0 as a parameter. This will transfer 0 ether. So one can reenter as much as one likes by always transferring 0 ether and subtracting 0 from 0. Not very useful and definitely not exploitable.
The next reentrancy pattern is broken in two ways:
Effectively dead code
Uses transfer, where reentrancy is not possible.
// 0 initialized and no function to update the mappingmapping(address=>uint) redeemableEther_re_ent25;
function claimReward_re_ent25() public {
// can never be satisfiedrequire(redeemableEther_re_ent25[msg.sender] >0);
// unreachableuint transferValue_re_ent25 = redeemableEther_re_ent25[msg.sender];
// msg.sender.transfer does not allow for reentrancy due to gas limitsmsg.sender.transfer(transferValue_re_ent25); //bug
redeemableEther_re_ent25[msg.sender] =0;
}
I suggest to put a big disclaimer somewhere that this dataset should not be used to evaluate reentrancy detection.
The text was updated successfully, but these errors were encountered:
Most of the injected bug patterns for reentrancy are not exploitable, or are even effectively dead code. This seems like a major drawback of this dataset when trying to evaluate reentrancy detection tools: the more precise a tool becomes, the worse it will perform on this dataset. In my opinion this is quite misleading.
The following pattern is injected into many of the contracts in the reentrancy category:
Now here
balances_re_ent17
is 0 initialized as all datatypes in Solidity/Ethereum. There is no way to change the values inbalances_re_ent17
. As such, the only valid call that does pass therequire
statement in the beginning ofwithdrawFunds_re_ent17
is to pass_weiToWithdraw == 0
as a parameter. This will transfer 0 ether. So one can reenter as much as one likes by always transferring 0 ether and subtracting 0 from 0. Not very useful and definitely not exploitable.The next reentrancy pattern is broken in two ways:
transfer
, where reentrancy is not possible.I suggest to put a big disclaimer somewhere that this dataset should not be used to evaluate reentrancy detection.
The text was updated successfully, but these errors were encountered: