Open c4-bot-5 opened 7 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 nullified
koolexcrypto marked the issue as not nullified
koolexcrypto marked the issue as not a duplicate
koolexcrypto marked the issue as primary issue
koolexcrypto marked the issue as selected for report
Hi @koolexcrypto,
I believe this should be dupped under #1001 with a partial-50 tag instead of treating it as a separate Medium-severity issue. #1001 demonstrates this issue in addition to the withdrawal blocking issue as well.
Linking this from the C4 Supreme Court behind my reasoning above as to why this should be dupped under #1001 with partial-grading.
Thank you for your time!
Hi @mcgrathcoutinho
Thank you for your feedback.
I understand your point. However, those are still two different issues. Preventing vault removal wouldn't occur without this condition Vault(vault).id2asset(id) > 0)
. Unfortunately, #1001 combined two in one.
Hi @koolexcrypto,
I still disagree.
Preventing vault removal wouldn't occur without this condition Vault(vault).id2asset(id) > 0)
And this condition Vault(vault).id2asset(id) > 0)
would only evaluate to true and revert if the attacker is able to deposit on behalf of a user.
Let's say we add the modifier isDNftOwner on the deposit() function, does the issue here require a separate mitigation in that case? - No
I'd also like to point out - that check is intended by the protocol so that users cannot remove vaults to protect their collateral during liquidations (see here).
If you still stand by your previous comment, I'd expect #1001 and dups mentioning withdrawal blocking + vault removal to be split into two issues if possible for fairness.
Sorry for commenting after PJQA and thanks!
For transparency, the DYAD team (shafu) confirmed this finding outside of github. The appropriate sponsor labeling has been added on their behalf.
Lines of code
https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L94-L104 https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L106-L116
Vulnerability details
Attacker can frontrun to prevent vaults from being removed from the dNFT owner's position
When removing a vault from a dNFT position, the vault must have no assets for that dNFT.
https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L94-L104
https://github.com/code-423n4/2024-04-dyad/blob/main/src/core/VaultManagerV2.sol#L106-L116
However, since anyone can deposit into a dNFT, anyone can prevent a vault from being removed from a dNFT position by observing the call to
remove()
in the mempool, and frontrunning the transaction by depositing dust amounts to the dNFT.Impact
Anyone can stop a vault from being removed from a dNFT position, at almost no cost.
If the victim has reached the max vault limit, they must remove a vault before adding a new one to their dNFT position. Therefore this vulnerability may force them to mint a new dNFT to use new vaults.
Proof of Concept
Add this file to
test/fork/
: https://gist.github.com/TheSavageTeddy/8dd94d8bb6a50459c5900e3b346afca5Run the test with
forge test --rpc-url https://eth-mainnet.g.alchemy.com/v2/<YOUR_KEY> --match-test "testDosRemoveVault" --fork-block-number 19693723 -vvv
The PoC demonstrates alice attempting to remove a vault from her dNFT position. She can do so as there are no assets in her position, but bob stops her by frontrunning her call to
remove()
, depositing 1 wei of ether into her dNFT.A snippet of the PoC is shown below:
Output:
Tools Used
Manual analysis
Recommended Mitigation Steps
Allow dNFT owners to remove vaults from their dNFT positions even if it has assets, but have a clear warning that doing so may reduce their collateral and cause liquidation.
Assessed type
Other