Beedle - Oracle free perpetual lending

Summary

The Lender.sol and Staking.sol have many areas where they are susceptible to potential reentrancy attacks since they are diverging from best practices with regards to the Checks-Effects-Interactions (CEI) pattern, which is a recommended best practice in Ethereum smart contract development.

Vulnerability Details

Within the setPool and the giveLoan functions of the contract, external calls are made to transfer tokens before updating internal states. Specifically:

1. In the setPool function:

   • Tokens are transferred using both transferFrom and transfer methods.

   • The pool's internal state is updated after these transfers.

2. In the giveLoan, buyLoan, and refinance functions:

   • There are transfers made, notably the protocol fee being transferred to the governance (feeReceiver).

   • Post this transfer, there are updates being made to the loan's internal state.

3. In the repay and seizeLoan functions:

• There are transfers made between the contract and the borrower.

• However, the delete loans[loanId] are updating the state after the transfers

In both functions, the failure to follow the CEI pattern can potentially expose the contract to reentrancy vulnerabilities.

Impact

A reentrancy attack occurs when an attacker can make a recursive call to the contract before the function finishes execution. If not properly protected against, an attacker could potentially drain funds or exploit the contract to their advantage.

Not adhering to the CEI pattern might also open doors to other unpredictable behaviors in the presence of malicious actors or in the event of unforeseen contract interactions.

Tools Used

Manual code review.

Recommendations

1. Always adhere to the CEI pattern: First, make all the necessary checks, then update the internal state, and lastly, interact with external contracts or addresses.

2. Use the reentrancyGuard modifier provided by OpenZeppelin's library. This modifier is designed to prevent reentrancy attacks.