turvec - Attackers can cause DOS attacks for tokens with Cap

[sherlock-admin3]

turvec

Medium

Attackers can cause DOS attacks for tokens with Cap

Summary

Attackers can prevent users from depositing certain tokens into the protocol, causing DOS attacks for tokens with Cap

Vulnerability Detail

Users are able to deposit tokens into the vault using the deposit() function, however, certain tokens have a deposit limit or cap:

    function deposit(ERC20 _token, uint256 _amount, address _receiver) public {
        uint256 cap = caps[address(_token)];

        if (cap != type(uint256).max) {
@>          if (_amount + _token.balanceOf(address(this)) > cap) {
                revert DepositExceedsCap();
            }
        }
         ...
    }

These tokens can also be withdrawn at any time through the withdraw() function with no regulation capabilities whatsoever:

function withdraw(ERC20 _token, uint256 _amount, address _receiver) public {
        balances[msg.sender][_token] -= _amount;

        _token.safeTransfer(_receiver, _amount);

        emit Withdraw(msg.sender, _receiver, address(_token), _amount);
    }

This allows attackers to run bots that monitor the deposit transactions to any of these capped tokens and front-run it to deposit the capped amount and then back-run it to withdraw out the amount, causing users' deposit transactions to those tokens to revert.
There are multiple reasons for attackers to perform such malicious attacks such as competitor advantage or blackhat reasons e.t.c

Impact

Attackers can cause DOS attacks for tokens with Cap

Code Snippet

PointTokenVault.sol#L118

Tool used

Manual Review

Recommendation

In order to prevent these attacks for tokens with caps, consider implementing a minimum cooldown on withdrawals and a regulating capability of penalizing such activities e.g slashing, temporary blocking or seizing of withdrawals for such blacklisted addresses.

[Alireza-Razavi]

This seems to be low due to sponsor's comment:

This is technically accurate, but would make little to no economic sense for an “attacker”. All funds used in the DOS attack would be permenantly lost by the attacker. The cap can extremely easily be raised. It only applies to transactions that would move the balance to exactly or just under the cap, which is presumable a very small subset of deposits into the vault

[turvec]

Escalate
The sponsor's comment might have misunderstood some points as these statements above are wrong.
Therefore I will give 2 further explanations:

1. All funds used in the DOS attack would be permanently lost by the attacker.

As explained in the report above, there is a withdraw() function with no time gap, blacklisting, or any regulation capabilities whatsoever, this allows the attacker to get back the funds used in the front run attack instantly with an immediate back-run.

2. It only applies to transactions that would move the balance to exactly or just under the cap, which is presumable a very small subset of deposits into the vault

These apply for any user depositing with any amount as long as attackers have the fund required for the cap

[sherlock-admin3]

Escalate
The sponsor's comment might have misunderstood some points as these statements above are wrong.
Therefore I will give 2 further explanations:

1. All funds used in the DOS attack would be permanently lost by the attacker.

As explained in the report above, there is a withdraw() function with no time gap, blacklisting, or any regulation capabilities whatsoever, this allows the attacker to get back the funds used in the front run attack instantly with an immediate back-run.

2. It only applies to transactions that would move the balance to exactly or just under the cap, which is presumable a very small subset of deposits into the vault

These apply for any user depositing with any amount as long as attackers have the fund required for the cap

The escalation could not be created because you are not exceeding the escalation threshold.

You can view the required number of additional valid issues/judging contest payouts in your Profile page,
in the Sherlock webapp.

[sherlock-admin2]

The protocol team fixed this issue in the following PRs/commits:
sense-finance/point-tokenization-vault#38

[sherlock-admin2]

The protocol team fixed this issue in the following PRs/commits:
sense-finance/point-tokenization-vault#38

[sherlock-admin2]

The Lead Senior Watson signed off on the fix.