DeFiHardhatOracleProxyUpdates
100,000 USDC
View results
Submission Details
Severity: high
Invalid

Reentrancy Vulnerabilitie in Silo.sol

Summary

Medium-severity reentrancy vulnerability in the _claimPlenty function of the Silo contract. The vulnerability arises from an external call to sopToken.safeTransfer preceding the modification of state variables, potentially exposing the contract to reentrancy attacks.

Vulnerability Details

The vulnerability stems from the sequence of operations in the _claimPlenty function, where tokens are transferred using sopToken.safeTransfer before deleting s.a[account].sop.plenty. This order of operations opens up the possibility of reentrancy attacks, as external calls can be manipulated to re-enter the function before the delete operation is completed.

Code Snippet:(contracts/beanstalk/silo/SiloFacet/Silo.sol#154-164)

function _claimPlenty(address account) internal {
// Plenty is earned in the form of the sop token.
uint256 plenty = s.a[account].sop.plenty;
IWell well = IWell(s.sopWell);
IERC20[] memory tokens = well.tokens();
IERC20 sopToken = tokens[0] != C.bean() ? tokens[0] : tokens[1];
sopToken.safeTransfer(account, plenty);
delete s.a[account].sop.plenty;
emit ClaimPlenty(account, address(sopToken), plenty);
}

Exploit Scenario
An attacker owning a malicious contract could exploit this vulnerability by triggering a reentrancy attack through a fallback function:

function fallback() external {
// Re-enter the vulnerable contract
vulnerableContract.claimPlenty(msg.sender);
}

If the sopToken.safeTransfer call in _claimPlenty triggers the attacker's fallback function, it could potentially re-enter the vulnerable contract before the delete operation, leading to unexpected state manipulation.

Impact

The impact of this vulnerability is substantial, warranting a "High" severity rating. A successful exploitation of the reentrancy vulnerability in the _claimPlenty function could lead to severe consequences. An attacker could manipulate the contract's state during execution, potentially resulting in unauthorized access to funds, unexpected contract behavior, or even a complete compromise of the contract's integrity. Considering the financial nature of the transactions involved, the potential for significant loss is high.

Tools Used

Manual review and slither.

Recommendations

Apply Check-Effects-Interactions Pattern: Modify the _claimPlenty function to follow the "check-effects-interactions" pattern, ensuring that state modifications occur before any external calls. Specifically, consider deleting s.a[account].sop.plenty before executing sopToken.safeTransfer.

Updates

Lead Judging Commences

giovannidisiena Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.