Depreciated function and frontunning on decreaseAllowance

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/token/ERC20.sol#L139
https://github.com/code-423n4/2023-09-centrifuge/blob/512e7a71ebd9ae76384f837204216f26380c9f91/src/token/ERC20.sol#L148

Vulnerability details

OpenZeppelin/openzeppelin-contracts#4585

These functions are not part of the EIP-20 specs.

These functions may allow for further phishing possibilities (instead of the common approve or permit ones; see e.g. just 12 hours ago someone lost $24m since he got tricked into signing a malicious increaseAllowance payload https://etherscan.io/tx/0xcbe7b32e62c7d931a28f747bba3a0afa7da95169fcf380ac2f7d54f3a2f77913).

The security concerns that fix increaseAllowance and decreaseAllowance are not critical in the wild (and both can be frontrunned also).

Impact

It invites phishing and frontrunning

This individual seems to be exploiting a certain feature quite effectively.

https://bscscan.com/tx/0x0b57d3847581c983e870a5237edc368e524c82cd8eb1037d98266613951fb7f8

In fact, I've noticed a lot of this activity on BSC, likely due to outdated and poorly implemented code.

https://bscscan.com/tx/0x0b57d3847581c983e870a5237edc368e524c82cd8eb1037d98266613951fb7f8#eventlog

I suspect this all started with a phishing allowance. It's evident right here.

However, this person seems to be benefiting significantly from this feature.

https://bscscan.com/tx/0x6b9f84fd535b234d461582d1adbdfec24f4f8f4a161523be34e91960e7dad9c0

Proof of Concept

    function increaseAllowance(address spender, uint256 addedValue) external returns (bool) {
        uint256 newValue = allowance[_msgSender()][spender] + addedValue;
        allowance[_msgSender()][spender] = newValue;


        emit Approval(_msgSender(), spender, newValue);


        return true;
    }


    function decreaseAllowance(address spender, uint256 subtractedValue) external returns (bool) {
        uint256 allowed = allowance[_msgSender()][spender];
        require(allowed >= subtractedValue, "ERC20/insufficient-allowance");
        unchecked {
            allowed = allowed - subtractedValue;
        }
        allowance[_msgSender()][spender] = allowed;


        emit Approval(_msgSender(), spender, allowed);


        return true;
    }

Tools Used

Manual Review

Recommended Mitigation Steps

Use safeIncreaseAllowance & safeDecreaseAllowance, it uses forceApproval. It's better to use non-depreciated standards to not affect future development.

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/60e3ffe6a3cc38ab94cae995bc1de081eed79335/contracts/token/ERC20/utils/SafeERC20.sol#L48-L69

Assessed type

ERC20

[c4-pre-sort]

raymondfam marked the issue as low quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #320

[c4-judge]

gzeon-c4 marked the issue as unsatisfactory:
Out of scope