Beedle - Oracle free perpetual lending

Summary

The seizeLoan function in the smart contract allows anyone to seize a loan after a failed refinance auction. However, the function is susceptible to arithmetic overflow and underflow issues during the calculation and deduction of the govFee. This vulnerability could result in incorrect fee calculations and improper transfers of collateral tokens.

Vulnerability Details

The vulnerable code snippet is as follows:

The vulnerability arises from the calculation of govFee, which multiplies the borrowerFee with the loan.collateral and then divides the result by 10000. If the value of borrowerFee exceeds 10000, an arithmetic overflow may occur during the multiplication, leading to an incorrect govFee. Subsequently, when this incorrect value is subtracted from loan.collateral, an arithmetic underflow can happen.

Impact

The arithmetic overflow and underflow can cause severe issues during the execution of the seizeLoan function. Incorrectly calculated govFee may result in an unintended transfer of collateral tokens, potentially leading to a loss of funds or disrupting the system's intended behavior.

Tools Used

Manual

Recommendations

To address this vulnerability, the contract should perform input validation to ensure that borrowerFee is within a valid range of 0 to 10000. Additionally, the contract should use SafeMath or a similar library to handle arithmetic operations safely, preventing potential overflow and underflow scenarios.

Severity:
The severity of this vulnerability can be considered as High.

Explanation:
The vulnerability in the seizeLoan function could result in arithmetic overflow and underflow, potentially leading to unintended transfers of collateral tokens. Depending on the values involved, this could have significant consequences, such as loss of funds, improper functioning of the system, or unexpected behavior in token transfers.

Moreover, as this function can be called by anyone, there is a possibility of malicious actors exploiting the vulnerability to manipulate fee calculations and token transfers to their advantage.

Given the potential for financial loss and disruption of the system's intended behavior, this vulnerability should be addressed urgently with proper input validation and SafeMath implementation to ensure secure and correct execution of the seizeLoan function.