Summary

There's a bad logic implementation in the redeem(IERC20 token, uint256 amountOfAssetToken) function, that vulnerability the LP to redeem more than what he's owed.

Vulnerability Details

Actors:
Attacker: the malicious LP that wants to redeem his funds.
Victim: Other LPs.
Protocol: The ThunderLoan contract itself.
Exploit Scenario:
Initial State: Protocl is depolyed, Attacker has already deposited some amounts.
Step 1: We know amountUnderlying depands on amountOfAssetToken because: uint256 amountUnderlying = (amountOfAssetToken * exchangeRate) / assetToken.EXCHANGE_RATE_PRECISION(); LPs can redeem more than they are owed from the protocol if they input a certain amountOfAssetToken such that: amountOfAssetToken > assetToken.balanceOf(msg.sender) && amountOfAssetToken < type(uint256).max. In order to max their profits they can input: amountOfAssetToken = type(uint256).max - 1. The attacker will also burn more than he should: assetToken.burn(msg.sender, amountOfAssetToken);

Impact

The attacker can redeem much more than what he's owed but will also burn more than he should

Tools Used

Manual review

Recommendations

• if (amountOfAssetToken == type(uint256).max) {

• amountOfAssetToken = assetToken.balanceOf(msg.sender);
  

• }

• require (amountOfAssetToken >= assetToken.balanceOf(msg.sender), "Not enough assetToekn in msg.sender's balance")