Closed c4-bot-8 closed 4 months ago
JustDravee marked the issue as high quality report
JustDravee marked the issue as primary issue
JustDravee marked the issue as duplicate of #489
koolexcrypto marked the issue as unsatisfactory: Invalid
koolexcrypto marked the issue as nullified
koolexcrypto marked the issue as not nullified
koolexcrypto marked the issue as duplicate of #1001
koolexcrypto marked the issue as satisfactory
Lines of code
https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L143 https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L127
Vulnerability details
Summary
The identified vulnerability in the
VaultManagerV2::withdraw
function allows for a denial-of-service (DoS) attack on the owner due to the ability of a malicious user to front-run the owner's withdrawal transaction. This attack leverages the restriction that deposit and withdraw operations cannot occur in the same block, causing the owner's withdrawal transaction to revert and effectively denying access to their funds.Vulnerability Details
The vulnerability stems from the following key aspects of the withdraw function:
The function checks if the
idToBlockOfLastDeposit[id]
is equal to the current block number (block.number
).If this condition is true (indicating that a deposit occurred in the same block), the function reverts with a
DepositedInSameBlock
error. This check prevents immediate withdrawals following a deposit in the same block. This is generally done to prevent flash loan attacks. However, a malicious user can exploit this behavior:By monitoring the blockchain for the owner's withdraw transaction, the malicious user can front-run that transaction and do a deposit of 0 amount within the same block.
If the malicious user successfully executes their deposit transaction first, it will cause the owner's withdrawal attempt to revert due to the block restriction check. This sequence of events results in a denial-of-service (DoS) attack, where the owner is unable to withdraw their funds as intended.
Proof of Concept
To run add the test and run:
forge test --fork-url <your mainnet rpc> --match-test testUserDoSWithdraw -vvv
We can see how by successfully front-running the owner's withdraw transaction the user DoSes the owner.
Impact
This attack disrupts the intended functionality of the withdrawal process and denies the owner access to their assets.
Tools Used
Manual Review
Recommended Mitigation Steps
One way to mitigate this and still leave the flash loan protection is to allow only the owner of the NFT to deposit into his vaults. This way a random user cannot perform this attack.
Assessed type
DoS