Open hats-bug-reporter[bot] opened 2 months ago
Mistake in the coded poc: forgot to vm.prank(user)
before fundingManager.deposit(1)
, but works the same
Amount of funds needed per token for the attacker to execute this attack (only some of the +$300M market cap tokens not including the absurd amount of memetokens)
Terra Classic
: $9562Pulse
: $4595eCash
: $3341Bittorrent
: $90APENFT
: $43Continuation of #145 as linked. If deemed valid by the other parties, will consider merging the 2 issues, this is just an exploit path of the original problem you reported.
It actually goes hand in hand with 15, 38 and 47 We will check it out internally how to handle the combination of these in the next few days
I agree that #145 is a duplicate of #15, but I think this submission is a a completely different attack scenario from these and the mentioned ones. It has a different and higher impact: it would DOS the whole system and gas-grief all depositing users (until governance action) without the attacker needing to cost any capital besides the gas-fees.
I would also like to mention that this issue is not limited to certain low $ value per wei tokens (although it's easiest to exploit with those) but by the attacker's capital. If we take the recommendations of the mentioned submissions this is still exploitable if the attacker holds enough funds or if the orchestrator owner set too low settings at initialization (while attackerFunds
> depositCap - userDepositAmount
).
I think it would be beneficial to consider a setter function for depositCap
(+ maxSupply
for consistency), beside setting these params at initialization since then the whole attack can be fixed by one TX by the orchestrator owner with setting a higher cap, if the initial one was vulnerable. I mentioned this in the initial submission.
Github username: @0xfuje Twitter username: 0xfuje Submission hash (on-chain): 0x7a4ed70844388a628a698c76306972e99f6d78b0e2fd48c4c6b4ad4ff7da4fcc Severity: high
Description:
Impact
Permanent denial of service of rebasing funding manager, gas griefing of depositors since their deposit will revert
Description
The root of the problem is that the
DEPOSIT_CAP
of rebasing funding manager is fixed and can be easily reachable to a large token holder, especially if the token has a low $ per wei ratio or a token with high decimals (more on this in #145). This is essentially a zero-cost griefing attack, if we are not including the gas fees, which are minimal because the project plans to deploy onOP
,Linea
andPolygon
currently and_deposit()
is not a very gas intensive operation. I can provide calculations with mainnet fees if needed.Proof of Concept - Described
10_000 * 1e18
tokens toFM_Rebasing_v1
DEPOSIT_CAP
amount of tokensDeposits already in place scenario
If there are already deposited funds, the attacker can spend
alreadyDepositedFundsInFundingManager
less to reach theDEPOSIT_CAP
to brick all new deposits.FM_Rebasing_v1.sol
-_deposit()
Proof of Concept - Coded
FM_Rebasing_v1.t.sol
run
forge test --match-test testDepositBrick -vvvv
Recommendation
Consider to allow an option to set a higher
depositCap
at initialization (and potentially a setter function for orchestrator admin). Consider to addfee
functionality toFM_Rebasing_v1.sol
funding manager: this would make it unpractical for an attacker to execute this griefing attack.