c4-bot-1 commented 8 months ago

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/transformers/V3Utils.sol#L631 https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L981 https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L423 https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/transformers/V3Utils.sol#L106 https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L720

Vulnerability details

Impact

The problem is fully described in the blog post by Trust Security. To summarize, since permit calls can be submitted by anyone, not just the signer, and executing a permit uses up a specific nonce, it is possible to extract a permit call from a transaction in the mempool, submit it, and get it executed. This can force the original transaction in the mempool to revert.

Both NonfungiblePositionManager's permit calls and the Permit2 library calls appear to be vulnerable. Since Revert Lend uses such calls in multiple places to authorize ERC20 and ERC721 token transfers as part of larger operations, it is vulnerable to this attack.

The impact of failed transactions can range from degraded UX and wasted gas fees to being unable to repay debts in time, and otherwise perform time-critical operations. This, in turn, can expose the user to liquidations and cause financial loss.

Tools Used

Manual review.

Recommended Mitigation Steps

Review the usage of permit calls in the code. One option is to wrap them in a try/catch block, using the TrustlessPermit library.

Assessed type

DoS

c4-pre-sort commented 8 months ago

0xEVom marked the issue as duplicate of #229

c4-pre-sort commented 8 months ago

0xEVom marked the issue as sufficient quality report

c4-judge commented 8 months ago

jhsagd76 changed the severity to QA (Quality Assurance)