Beedle - Oracle free perpetual lending

Summary

I discuss a vulnerability related to the calculation of loan ratios within a lending protocol. The vulnerability stems from a mismatch in the decimal places of the debt and collateral tokens, leading to incorrect loan ratio calculations. This issue affects functions such as giveLoan() and refinance(). The impact of this vulnerability is demonstrated using an example where a user can borrow significantly more than intended due to the decimal mismatch. This could potentially lead to funds being drained from the lending pool by malicious borrowers. The text suggests two possible solutions: ensuring that the debt and collateral tokens have the same number of decimals or normalizing the decimals to match the token with more decimals.

Vulnerability Details

The vulnerability pertains to loan borrowing and the calculation of the loanRatio, which should remain below the pool.maxLoanRatio. Notably, pool.maxLoanRatio is defined with 18 decimals. The loanRatio is determined by the equation:

However, this calculation assumes uniform decimal counts for both debt and collateral, which may not be the case. If, for instance, debt has 6 decimals while collateral has 18 decimals, borrowers could exploit this disparity to borrow up to 12 times the intended amount without triggering the pool.maxLoanRatio safeguard. This issue is also present in the giveLoan() and refinance() functions.

Impact

Imagine a scenario with a pool.maxLoanRatio of 1 (expressed as 1e18 due to decimals). Consider debt token as USDT with 6 decimals and collateral token as ETH with 18 decimals. While aiming to borrow $100 worth of USDT, users should normally provide at least $100 worth of ETH. However, due to the decimal mismatch, borrowers can borrow well beyond $100 of USDT.

With $100 USDT represented as 100 * 1e6, and $100 ETH as 100 * 1e18, the ideal loan ratio is 1 (equivalent to 1e18). Yet, the calculated loan ratio becomes (represented as 1e6):

Consequently, users could borrow over times the intended amount. Malicious borrowers could exploit this anomaly to drain a pool's funds by paying relatively small amounts while receiving substantial sums.

Tools Used

Manual Review

Recommendations

To address this vulnerability, two mitigation strategies are proposed:

1. A straightforward yet imperfect approach: Ensure that the collateral and debt tokens possess matching decimal counts.

2. A more intricate but robust solution: Normalize decimals to match the token with the higher decimal count.