The Standard

Summary

Due to the lack of access control and no check if asset.amount == msg.value, an attacker can call LiquidationPool.distributeAssets() passing arbitrary amounts of native token as argument to the function, enabling then to burn EURO from LiquidationPool and increase rewards at will.

Vulnerability Details

LiquidationPool.distributeAssets() is responsible for computing and assigning rewards for the stakers in the LiquidationPool. It takes an array of ILiquidationPoolManager.Asset as input, which contains all the collateral funds obtained from the liquidation of a vault. The function then iterates over these assets, processes the received amounts, and sets the corresponding rewards.

For ERC20 tokens, they are transferred from the LiquidationPoolManager to the LiquidationPool contract for later claiming by stakers. However, when processing native tokens, it is implicitly assumed that these funds were sent during the call to LiquidationPool.distributeAssets(), as there is no check to confirm whether msg.value matches the amount value inside the assets array. The absence of access control in distributeAssets() means that an attacker can call the function with arbitrary amounts of native tokens in the assets array without actually sending any native tokens.

As outlined above, by calling LiquidationPool.distributeAssets() with a manipulated array containing arbitrary amounts of native tokens, an attacker can burn any desired amount of EURO from the LiquidationPool balance and artificially inflate rewards. However, since the rewards increase without actual fund deposits, some users may be able to withdraw more than they are entitled to, while others may be unable to withdraw at all. The first claimers will withdraw all available funds, leaving insufficient native funds for subsequent claimants.

Impact

The impact is twofold: Firstly, the attacker can force the LiquidationPool to burn EURO balances at will.

Secondarily, rewards will be overestimated, allowing some stakers to claim more rewards than they deserve, while those claiming later may find themselves unable to claim at all due to the prior excessive claims, resulting in an insufficient pool of native funds for everyone to claim.

Tools Used

Manual Review.

Recommended Mitigation

Consider checking if asset.amount == msg.value when asset.token.addr == address(0).