Medium4-StorageOccupation-CarlosAlegreUr

Severity

Medium Risk

Relevant GitHub Links

https://github.com/Cyfrin/2023-07-beedle/blob/main/src/Lender.sol

Software Audit Report 📑

Summary 📌

This report outlines potential exploits where well-funded attackers might tamper with the contract's storage slots, leading to higher operational costs.

Vulnerability Details 🔍

In Lender.sol:

Exploits by Attackers with Enough Capital

📘 Notice ℹ️: Some solutions are explained in the Recommendations section. They may differ in implementation so I've linked trusted implementations like OpenZeppelin contracts.

Infinite Pool Creation:
- Problem 🚧: The contract allows infinite pool creation, opening doors for DoS attacks via storage slot occupancy, increasing transaction costs.
Unregulated Loans Creation & Borrowing:
- Problem 🚧: Any address can establish a pool and increase the size of the loans array by borrowing insignificant tokens.
No Control over Tokens Used for Lending:
- Problem 🚧: Absence of mechanisms to control tokens lets attackers manipulate the system with only the cost of gas fees and function calls.

Impact 📈

Redundant storage utilization can increase operational expenses.

Tools Used 🛠️

Manual audit.
Slither.

Recommendations 🎯

Considering future plans for a governance model here are some suggestions to face the problems:

Authorizing the governance to blacklist suspicious addresses.
Infinite Pool Creation:
- Cap the number of pools an individual can establish.
- Use a variable like mapping(address => uint256) addressToNumOfPoolsCreated.
- Introduce a constant like MAX_POOLS_PER_USER.
- Adjust the mapping number each time a pool is created or deleted.
- Mark the setPool() function as non-reentrant, slowing the rate of pool creation and providing the governance more reaction time. For this, you can use OpenZeppelin's ReentrancyGuard.
Infinite Loans:
- Impose a cap on borrowings per address, similar to how it's addressed in the pool limits solution.
- Note a potential reentrancy vulnerability with fake IERC20 contracts during borrow() calls. Again, use ReentrancyGuard to mitigate this risk.
Token Control Solutions:
- Enforce token whitelist/blacklist methods. For that, you could use roles from OpenZeppelin's AccessControl.
- Propose a fee for pool creation or an assurance mechanism with a valuable asset, such as the native blockchain coin, reclaimable once the lending is over.

🚧 Note ⚠️: Implementing solutions to these problems requires significant code modification. A second audit is recommended post-implementation to ensure no new bugs are introduced.

Cyfrin / 2023-07-beedle

Medium4-StorageOccupation-CarlosAlegreUr #260