The Standard

Summary

LiquidationPool assumes the token decimals of the result provided by Chainlink. This could result in loss of rewards and stuck funds.

Vulnerability Details

LiquidationPool::distributeAssets function uses the Chainlink price feed of token / USD and assumes that the result of this price feed would be with 8 decimal precision, however if we look at the Chainlink price feeds (https://docs.chain.link/data-feeds/price-feeds/addresses?network=ethereum&page=1&search=USD) we can see that not all pairs are with 8 decimal precision. For example AMPL / USD price feed returns the answer with 18 decimals. This means that if the protocol decides to whitelist the AMPL token the rewards that we get from this token will equal to 0 even though the tokens are transferred to the contract. Let me explain how that can happen:
The problem arises when trying to calculate the value of the portion that we want to distribute each holder. We use costInEuros variable to calculate that and to do so we take the amount of tokens that is intended for us and we convert it to EURO. This variable is supposed to be with 18 decimal precision, however if Chainlink pricefeed token / USD returns 18 decimals (for example with AMPL) then costInEuros will be with 28 decimals (18+18-8=28). Then to calculate our portion we use _portion = _portion * _position.EUROs / costInEuros and this would result in 0. (portion is 9 decimals + EURO is with 18 meaning we have 1e27 decimal number and we divide it by 1e28 decimal number, resulting in 0 in our case)
Therefore the rewards of every holder will increase by 0 and decrease our position of EUROs tokens to 0 because of this line costInEuros = _position.EUROs. That will leave the tokens stuck in the contract.

Impact

Incorrect distribution of rewards and stuck tokens

Tools Used

Manual Review

Recommendations

Use the decimals function provided by Chainlink. When calculating costInEuros scale both assetPriceUsd and priceEurUsd to 18 decimal precision by using the decimals from Chainlink. This will ensure that costInEuros is always with 18 decimal precision.