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
The deposits array of BountyStorageCore contract is unbound, along with the for loop read in getLockedFunds() function which is called by refundDeposit(), lead to a realistic DoS attack vector which would prevent any users from refund.
Vulnerability Detail
Let's illustrate why DoS attack is realistic and feasible.
As shown on L54 of BountyStorageCore contract and L34~L36 of receiveFunds() function
Each time an deposits item is added, there is 4 additional SLOAD instructions overhead. As one SLOAD costs 2100 gas, so each deposits item costs more than 8400 additional gas to call getLockedFunds() function. As the max gas limit of block is 30M, we can calculate the minimum DoS deposits by
minDoSDeposits = 30M /8400=3572
So if there is more than 3572 deposits, then any transactions containing call to getLockedFunds() can't be mined. It looks like a big number, but the contract will be deployed on Polygon chain, the gas cost for executing one deposit is only about $0.02 (reference). As depositing volume of token can be as low as 1 WEI, the total cost for a successful DoS attack is pretty much the total gas cost which is about
costOfDoSAttack =3572* $0.02= $71.44
We can see the cost is low, so the attack is realistic and feasible.
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
KingNFT
medium
DoS attack on unbound
deposits
arraySummary
The
deposits
array ofBountyStorageCore
contract is unbound, along with thefor
loop read ingetLockedFunds()
function which is called byrefundDeposit()
, lead to a realistic DoS attack vector which would prevent any users fromrefund
.Vulnerability Detail
Let's illustrate why DoS attack is realistic and feasible.
As shown on L54 of
BountyStorageCore
contract and L34~L36 ofreceiveFunds()
functionThere is no limit on the
deposits
array length.Next let's look at the
for
loop ingetLockedFunds()
function, L341-349 ofBountyCore
contractEach time an
deposits
item is added, there is 4 additionalSLOAD
instructions overhead. As oneSLOAD
costs 2100 gas, so eachdeposits
item costs more than 8400 additional gas to callgetLockedFunds()
function. As the max gas limit of block is 30M, we can calculate the minimum DoSdeposits
bySo if there is more than 3572 deposits, then any transactions containing call to
getLockedFunds()
can't be mined. It looks like a big number, but the contract will be deployed on Polygon chain, the gas cost for executing one deposit is only about $0.02 (reference). As depositingvolume
of token can be as low as 1 WEI, the total cost for a successful DoS attack is pretty much the total gas cost which is aboutWe can see the cost is low, so the attack is realistic and feasible.
Impact
The attack would prevent any users from
refund
Code Snippet
https://github.com/sherlock-audit/2023-02-openq/blob/main/contracts/Bounty/Storage/BountyStorageCore.sol#L54
https://github.com/sherlock-audit/2023-02-openq/blob/main/contracts/Bounty/Implementations/BountyCore.sol#L333-L352
Tool used
Manual Review
Recommendation
Limit the minimum depositing
volume
.Duplicate of #77
The text was updated successfully, but these errors were encountered: