code-423n4 / 2024-07-reserve-validation

0 stars 0 forks source link

Use of the deprecated `safeApprove()` function of openzeppelin containing security vulnerabilities. #175

Closed c4-bot-10 closed 1 month ago

c4-bot-10 commented 1 month ago

Lines of code

https://github.com/code-423n4/2024-07-reserve/blob/3f133997e186465f4904553b0f8e86ecb7bbacbf/contracts/p1/BackingManager.sol#L72 https://github.com/code-423n4/2024-07-reserve/blob/3f133997e186465f4904553b0f8e86ecb7bbacbf/contracts/p1/BackingManager.sol#L73 https://github.com/code-423n4/2024-07-reserve/blob/3f133997e186465f4904553b0f8e86ecb7bbacbf/contracts/p1/RevenueTrader.sol#L191 https://github.com/code-423n4/2024-07-reserve/blob/3f133997e186465f4904553b0f8e86ecb7bbacbf/contracts/p1/RevenueTrader.sol#L192

Vulnerability details

Impact

The BackingManager::grantRTokenAllowance and the RevenurTrader::_distributeTokenToBuy functions make use of safeApprove() function. The original ERC20 token approval function is susceptible to front-running attacks, where malicious actors can modify quotas after seeing a transaction, but before it is mined. The safeApprove function inherited this vulnerability and added unnecessary complexity, making it an additional insecurity. This is why both functions have been deprecated.

Proof of Concept

@> tokenToBuy.safeApprove(address(distributor), 0); @> tokenToBuy.safeApprove(address(distributor), bal);

    distributor.distribute(tokenToBuy, bal);
}


## Tools Used
Manual anlysis.

## Recommended Mitigation Steps
Instead of using `safeApprove`, OpenZeppelin introduced `safeIncreaseAllowance` and `safeDecreaseAllowance` functions in the SafeERC20 library, which allow you to safely increment or decrement the allowance without directly setting it to a specific value.

## Assessed type

ERC20