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

TokenManager::withdraw Misses Approval for ERC20 Tokens Beside WETH

4rdiii

[H-03] TokenManager::withdraw Misses Approval for ERC20 Tokens Beside WETH

Summary

The withdraw function operates with both ERC20 and native Ethereum (WETH9 token) assets. For WETH9, it leverages the _transfer function to retrieve funds from the CapitalPool, which internally manages approval. Conversely, when dealing with other ERC20 tokens, it resorts to the inherited Rescuable::_safe_transfer_from method to directly transfer these tokens from the CapitalPool to the user. This methodology introduces a vulnerability since the _safe_transfer_from function fails to secure approval from the CapitalPool through its approve function. As a result, user-initiated withdrawals may encounter reversion errors.
Note: there is a somewhat similar issue with _transfer function getting approval but for this case we assumed that its working correctly.

Vulnerability Details

The provided code snippets illustrate the withdraw and _safe_transfer_from function implementations, emphasizing that neither invokes the CapitalPool::approve method.

function withdraw(
address _tokenAddress,
TokenBalanceType _tokenBalanceType
) external whenNotPaused {
uint256 claimAbleAmount = userTokenBalanceMap[_msgSender()][
_tokenAddress
][_tokenBalanceType];
​
if (claimAbleAmount == 0) {
return;
}
​
address capitalPoolAddr = tadleFactory.relatedContracts(
RelatedContractLibraries.CAPITAL_POOL
);
​
if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @dev transfer from capital pool to msg sender
* @dev withdraw native token to token manager contract
* @dev transfer native token to msg sender
*/
_transfer(
wrappedNativeToken,
capitalPoolAddr,
address(this),
claimAbleAmount,
capitalPoolAddr
);
​
IWrappedNativeToken(wrappedNativeToken).withdraw(claimAbleAmount);
payable(msg.sender).transfer(claimAbleAmount);
} else {
/**
* @dev token is ERC20 token
* @dev transfer from capital pool to msg sender
*/
@> _safe_transfer_from(
@> _tokenAddress,
@> capitalPoolAddr,
@> _msgSender(),
@> claimAbleAmount
@> );
}
​
function _safe_transfer_from(
address token,
address from,
address to,
uint256 amount
) internal {
(bool success, ) = token.call(
abi.encodeWithSelector(TRANSFER_FROM_SELECTOR, from, to, amount)
);
​
if (!success) {
revert TransferFailed();
}
}

Impact

This issue could lead to user funds (excluding WETH9 or native tokens) remaining locked within the CapitalPool, necessitating manual intervention either via the rescue function on CapitalPool or by manually approving each token on CapitalPool.

Proof of Concept

To demonstrate this issue, consider adding the following test to the existing test suite:

function test_my_fund_stuck_missing_approval() public {
vm.prank(user);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
0.01 * 1e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Turbo
)
);
vm.startPrank(user);
address _stock = GenerateAddress.generateStockAddress(0);
address _offer = GenerateAddress.generateOfferAddress(0);
preMarktes.closeOffer(_stock, _offer);
vm.expectRevert(Rescuable.TransferFailed.selector);
tokenManager.withdraw(
address(mockUSDCToken),
TokenBalanceType.MakerRefund
);
}

Tools Used

Manual Review

Recommendations

To mitigate this vulnerability, ensure approval is granted before invoking _safe_transfer_from or utilize the _transfer method, which inherently handles approval.

function withdraw(
address _tokenAddress,
TokenBalanceType _tokenBalanceType
) external whenNotPaused {
uint256 claimAbleAmount = userTokenBalanceMap[_msgSender()][
_tokenAddress
][_tokenBalanceType];
​
if (claimAbleAmount == 0) {
return;
}
​
address capitalPoolAddr = tadleFactory.relatedContracts(
RelatedContractLibraries.CAPITAL_POOL
);
​
if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @dev transfer from capital pool to msg sender
* @dev withdraw native token to token manager contract
* @dev transfer native token to msg sender
*/
_transfer(
wrappedNativeToken,
capitalPoolAddr,
address(this),
claimAbleAmount,
capitalPoolAddr
);
​
IWrappedNativeToken(wrappedNativeToken).withdraw(claimAbleAmount);
payable(msg.sender).transfer(claimAbleAmount);
} else {
/**
* @dev token is ERC20 token
* @dev transfer from capital pool to msg sender
*/
+ ICapitalPool(capitalPoolAddr).approve(_tokenAddress);
_safe_transfer_from(
_tokenAddress,
capitalPoolAddr,
_msgSender(),
claimAbleAmount
);
}
​
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.