Beedle - Oracle free perpetual lending

Summary

In my review of the provided smart contract, I identified an unprotected external call that could expose the system to a reentrancy attack. Specifically, the contract executes external transfers using the transfer and transferFrom methods of the ERC20 token before its internal state is updated. By crafting a malicious fallback function in their contract, an attacker could potentially exploit this, re-entering and interacting with the original contract multiple times before its state is finalized. This vulnerability could lead to unintended behaviors, including potential fund losses or other unexpected state alterations.

Vulnerability Details

In each of these functions, the contract interacts with external contracts (in the form of token transfers) before updating its internal state. This pattern can be exploited by an attacker, especially if they control the external contract being interacted with.

Function: setPool()

In the setPool function, the contract transfers tokens before updating its internal state. An attacker could exploit this by creating a malicious ERC20 token that triggers a callback to the setPool function.

Function: 'borrow()`

The borrow function transfers loan tokens to the borrower and then transfers collateral tokens from the borrower. This sequence can be exploited if the borrower uses a malicious token contract.

Function: repay()

Function: giveLoan()

The giveLoan function transfers protocol interest to the fee receiver before updating the loan's internal state, which can be exploited.

Function: buyLoan()

Similarly, in the buyLoan function, the contract transfers protocol interest before updating the loan's state, making it vulnerable.

Function: refinance()

The refinance function transfers loan tokens and protocol interest before updating the loan's state, making it vulnerable to reentrancy attacks.

Impact

The reentrancy vulnerability in this contract poses a significant risk to both the contract's integrity and the funds it manages. If exploited, an attacker could potentially drain funds from the contract or manipulate its state to their advantage. This could lead to financial losses for users and damage the trustworthiness of the platform. Additionally, the vulnerability could be used in conjunction with other vulnerabilities, amplifying the potential damage. The contract's operations could be disrupted, and its reputation could suffer irreparably. Addressing this vulnerability is crucial to ensure the safety and reliability of the system.

Tools Used

VSCode, Slither

Recommendations

• Use ReentrancyGuard: Implement the ReentrancyGuard modifier provided by OpenZeppelin's contracts. This modifier prevents recursive calls by blocking external calls while a function is being executed.

• State Changes Before External Calls:
  Always update the contract's state before making an external call. This ensures that even if a reentrant call is made, the contract's state is already updated, and the function will not execute with the previous state.