Beedle - Oracle free perpetual lending

Summary

Classic same function reentrancy callback risk potential in setPool() function by rogue lender IF ERC20 token type used enables callbacks.

Combine this potential risk with my report #12 finding of CEI violation, (https://github.com/Cyfrin/2023-07-beedle/blob/d9718f2ca6521756624c017c90f3d4d4e80da90c/src/Lender.sol#L167-L175), for attack vector, which IF successful, can potentially drain the Lender contract from some/all funds.

Vulnerability Details

Simple "PoC":

Rogue lender creates pool with some liquidity, then calls setPool() sometime later with new pool config specifically to reduce the current pool's loanToken balance, and because the state mapping has not been updated yet due to above CEI violation finding, the rogue lender only needs to be using an ERC20 token type for the loanToken which enables callbacks, and call back into the setPool() function to repeat and transfer more loanToken back to lender's wallet/contract.

Another attack angle could be to call the addToPool() function instead, to simultaneously drain the Lender contract and add those same funds back into the pool but this time record it under rogue lender's mapping record, to make it seem slightly more legit, and then withdraw the funds later, as to not rise suspicion too easily/quickly.

Impact

can potentially drain the Lender contract from some/all funds

Tools Used

VSC, manual.

Recommendations

• Use Checks-Effects-Interactions Pattern (CEI)

• Implement Reentrancy Guards