-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
0xarno - **Attacker Can Cause DoS in SuperPool Deployment** #485
Comments
escalate: |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
I disagree with the escalation. @ARNO-0 You haven't provided any additional information about why it should be High. For me, this severity is at most Medium. Planning to reject the escalation and leave the issue as is. |
@cvetanovv I disagree with the decision to keep this as medium because of the following reasons:
|
The imact is the most Medium. |
Result: |
Escalations have been resolved successfully! Escalation status:
|
0xarno
High
Attacker Can Cause DoS in SuperPool Deployment
Summary
An attacker can exploit the predictable address of a newly deployed
SuperPool
contract to deposit assets before the contract is officially deployed. This leads to the initial deposit by the contract owner minting fewer than the required 1000 shares, causing a denial of service (DoS) on the contract deployment process.Vulnerability Detail
When a new
SuperPool
is deployed, its address can be predicted using the contract's nonce and the deployer's address. An attacker can take advantage of this by sending assets to the precomputed address before theSuperPool
contract is deployed. The factory contract relies on the initial deposit to mint a minimum of 1000 shares, which are then burned. However, if the attacker has already sent assets to the precomputed address, the initial deposit by the contract owner will mint fewer than 1000 shares, causing the deployment process to revert.Impact
This vulnerability allows an attacker to effectively block the deployment of new
SuperPool
contracts by causing theSuperPoolFactory_TooFewInitialShares
error to be triggered. The deployer would need to deposit 1000 times the amount of assets already present in the contract to meet the minimum share requirement, making it infeasible to deploy the contract.Code Snippet
https://github.com/sherlock-audit/2024-08-sentiment-v2/blob/main/protocol-v2/src/SuperPoolFactory.sol#L75
Coded PoC
The following proof of concept (PoC) demonstrates the attack:
Tool used
Manual Review
Recommendation
To mitigate this issue, transfer the asset balance in the constructor of the
SuperPool
contract.Duplicate of #97
The text was updated successfully, but these errors were encountered: