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

Inconsistent Approval Logic Leading to Failed Transfers for Non-Native Tokens

aksoy

Summary

The approval process for non-native tokens is not properly handled inside TokenManager contract and user cant withdraw if CapitalPool::approve() not called separately.

Vulnerability Details

In the withdraw function, when withdrawing non-native tokens (ERC20 tokens), the contract attempts to transfer tokens from the CapitalPool to the user using the _safe_transfer_from function. However, the required approval for this transfer is not guaranteed because the approval logic in the _transfer function is only executed under specific conditions that are not met for non-native token withdrawals. The main reason for this problem is, this is the only place that will call CapitalPool.approve(); for non-native tokens , user withdrawals will fail until separate call to the CapitalPool.approve();

function withdraw(
address _tokenAddress,
TokenBalanceType _tokenBalanceType
) external whenNotPaused {
​
// ...
if (_tokenAddress == wrappedNativeToken) {
// Handles native token withdrawal
_transfer(...);
} else {
// Handles ERC20 token withdrawal
_safe_transfer_from(
_tokenAddress,
capitalPoolAddr,
_msgSender(),
claimAbleAmount
);
}
function _transfer(
address _token,
address _from,
address _to,
uint256 _amount,
address _capitalPoolAddr
) internal {
uint256 fromBalanceBef = IERC20(_token).balanceOf(_from);
uint256 toBalanceBef = IERC20(_token).balanceOf(_to);
​
if (
_from == _capitalPoolAddr &&
IERC20(_token).allowance(_from, address(this)) == 0x0
) {
ICapitalPool(_capitalPoolAddr).approve(address(this));
}

https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/TokenManager.sol#L175

Impact

If the required approval is not in place, any attempt to transfer ERC20 tokens using the withdraw function could fail. This would prevent users from withdrawing their ERC20 tokens

Tools Used

manual

Recommendations

use internal _transferfunction instead of _safe_transfer_from to check token allowance

} else {
/**
* @dev token is ERC20 token
* @dev transfer from capital pool to msg sender
*/
- _safe_transfer_from(
- _tokenAddress,
- capitalPoolAddr,
- _msgSender(),
- claimAbleAmount
- );
+ _transfer(
+ _tokenAddress,
+ capitalPoolAddr,
+ _msgSender(),
+ claimAbleAmount,
+ capitalPoolAddr
+ );
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.