Tadle
Tadle
DeFiFoundry
27,750 USDC
View results
Previous Next
Submission Details
Severity: high
Valid

Missing `CapitalPool.approve()` call when `TokenManager.withdraw()` is called can result in DoS and funds lock.

eeyore

Summary

Within the contract, there is nowhere to find a CapitalPool.approve() call that is needed to perform _safe_transfer_from within TokenManager during the withdrawal of ERC20 tokens.

Vulnerability Details

Without the CapitalPool.approve() call for the ERC20 token that the user wants to withdraw via the TokenManager.withdraw() function, all transactions will be reverted, and funds will be locked in the system.

File: TokenManager.sol
171: /**
172: * @dev token is ERC20 token
173: * @dev transfer from capital pool to msg sender
174: */
175: _safe_transfer_from(
176: _tokenAddress, // <== within the code there is no approval made for _tokenAddress
177: capitalPoolAddr,
178: _msgSender(),
179: claimAbleAmount
180: );

Currently, this is only a temporary DoS due to another error in CapitalPool.approve(): missing access control check, so it is possible to call CapitalPool.approve() manually and prevent the DoS.

But when fixed, the above issue will surface.

Impact

  • DoS.

  • Lock of funds.

Tools Used

Manual review.

Recommendations

Before calling _safe_transfer_from in TokenManager, a proper check needs to be done to ensure that the proper allowance is set.

Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-TokenManager-safeTransferFrom-withdraw-missing-approve

This issue's severity has similar reasonings to #252, whereby If we consider the correct permissioned implementation for the `approve()` function within `CapitalPool.sol`, this would be a critical severity issue, because the withdrawal of funds will be permanently blocked and must be rescued by the admin via the `Rescuable.sol` contract, given it will always revert [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/CapitalPool.sol#L36-L38) when attempting to call a non-existent function selector `approve` within the TokenManager contract. Similarly, the argument here is the approval function `approve` was made permisionless, so if somebody beforehand calls approval for the TokenManager for the required token, the transfer will infact not revert when a withdrawal is invoked. I will leave open for escalation discussions, but based on my first point, I believe high severity is appropriate. It also has a slightly different root cause and fix whereby an explicit approval needs to be provided before a call to `_safe_transfer_from()`, if not, the alternative `_transfer()` function should be used to provide an approval, assuming a fix was implemented for issue #252

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.