Closed c4-bot-5 closed 6 months ago
JustDravee marked the issue as duplicate of #489
JustDravee marked the issue as sufficient quality report
koolexcrypto marked the issue as unsatisfactory: Invalid
koolexcrypto marked the issue as unsatisfactory: Invalid
koolexcrypto marked the issue as duplicate of #1001
koolexcrypto marked the issue as satisfactory
koolexcrypto changed the severity to 3 (High Risk)
Lines of code
https://github.com/code-423n4/2024-04-dyad/blob/4a987e536576139793a1c04690336d06c93fca90/src/core/VaultManagerV2.sol#L119
Vulnerability details
Impact
As anyone can deposit funds into a DNFT, a malicious user can deposit a small amount and set the
idToBlockOfLastDeposit
to the most recent block, disabling withdrawals from a certain DNFT ID. This can be done continuously (in every block, which is quite gas costly but still doable in a specific amount of time) or can be done via frontrunning and only when the owner of the DNFT intends to withdraw. Causing Liquidity Providers difficulties in withdrawing their deposits.Proof of Concept## Proof of Concept
Add the following test to
test/frol/v2.t.sol
. Exploit Steps:Tools Used
Recommended Mitigation Steps
To fix this issue, you can either completely stop other users from depositing into a DNFT, or if that's not possible or changes the protocol design, set a minimum deposit (e.g., 0.1 wETH). Here is a simple example in which I added a min deposit (note that it only works for weth and not other tokens, you should probably set min amount based on vault asset type)
Assessed type
DoS