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
{{ message }}
This repository has been archived by the owner on May 26, 2023. It is now read-only.
github-actionsbot opened this issue
Feb 21, 2023
· 0 comments
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
Although the amount of token addresses are limited to avoid DoS, the amount of deposits are not limited.
To receive a refund, every deposit must be looped through to determine how much of the token balance is currently able to be refunded. This array can be arbitrarily increased to make it out-of-gas on every attempt to get a refund, therefore completely DoSing a user's ability to get a refund.
When combined with a DoS on claims, this will permanently lose all funds in the contract.
Vulnerability Detail
Create many deposits with a very small amount of Ether each.
Once you have enough, any attempts at refunds will revert.
This can lead to permanent loss of all funds in the contract.
Impact
High because it can lead to permanent loss of all funds.
These lines show where claims require this loop to be run and the loop that is being run.
Tool used
Manual Review
Recommendation
I'm not sure exactly what would be best for you guys, but maybe a minimum amount of tokens to be deposited, a maximum amount of deposits, or another way of determining locked funds amount that doesn't require a loop.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
Robert
high
Block All Refunds By Adding Many Deposits
Summary
Although the amount of token addresses are limited to avoid DoS, the amount of deposits are not limited.
To receive a refund, every deposit must be looped through to determine how much of the token balance is currently able to be refunded. This array can be arbitrarily increased to make it out-of-gas on every attempt to get a refund, therefore completely DoSing a user's ability to get a refund.
When combined with a DoS on claims, this will permanently lose all funds in the contract.
Vulnerability Detail
Impact
High because it can lead to permanent loss of all funds.
Code Snippet
https://github.com/sherlock-audit/2023-02-openq/blob/main/contracts/DepositManager/Implementations/DepositManagerV1.sol#L172
https://github.com/sherlock-audit/2023-02-openq/blob/main/contracts/Bounty/Implementations/BountyCore.sol#L341
These lines show where claims require this loop to be run and the loop that is being run.
Tool used
Manual Review
Recommendation
I'm not sure exactly what would be best for you guys, but maybe a minimum amount of tokens to be deposited, a maximum amount of deposits, or another way of determining locked funds amount that doesn't require a loop.
Duplicate of #77
The text was updated successfully, but these errors were encountered: