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

Missing `CapitalPool::approve` prevents ERC20 token withdrawals from the protocol

tnevler

Summary

TokenManager::withdraw is designed to allow users to withdraw available funds from the protocol. However, there is a missing statement and that disallows to retrieve available funds if a user want to withdraw ERC20 tokens from the protocol.

Vulnerability Details

When dealing with ERC20 tokens, the issue arises because TokenManager::withdraw is missing the CapitalPool::approve call before invoking the _safe_transfer_from function. Consequently, the transaction always reverts with the following error: ERC20InsufficientAllowance.

Code Snippet

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
);
}
​
emit Withdraw(
_msgSender(),
_tokenAddress,
_tokenBalanceType,
claimAbleAmount
);
}

Impact

The vulnerability prevents users from withdrawing ERC20 tokens from the protocol. This means that all the ERC20 tokens sent to the contract would be stuck.

Proof Of Concept

  1. User calls PreMarket::createOffer function.

  2. User1 calls PreMarket:createTaker function.

  3. User calls withdraw() function, and it reverts with TransferFailed error.

Place this into the PreMarkets.t.sol file and execute the following command:

forge test --mt test_withdrawRevertsWithoutApprove -vvvv

error TransferFailed();
function test_withdrawRevertsWithoutApprove() public {
vm.startPrank(user);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
0.01 * 1e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Protected
)
);
​
address offerAddr = GenerateAddress.generateOfferAddress(0);
vm.stopPrank();
​
vm.startPrank(user1);
mockUSDCToken.approve(address(tokenManager), type(uint256).max);
preMarktes.createTaker(offerAddr, 300);
vm.stopPrank();
vm.startPrank(user);
vm.expectRevert(TransferFailed.selector);
tokenManager.withdraw(address(mockUSDCToken), TokenBalanceType.SalesRevenue);
vm.expectRevert(TransferFailed.selector);
tokenManager.withdraw(address(mockUSDCToken), TokenBalanceType.TaxIncome);
vm.stopPrank();
}

Tools Used

Manual testing

Foundry

Recommended Mitigation

There are a few recommended mitigations here.

  • Instead of calling the _safe_tranfer_from function, use the _transfer function.

} 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
+ );
}

(TokenManager::_transfer contains another vulnerability described in the submission "Funds are stuck in the protocol because of approve(address(this))")

  • Alternatively, call CapitalPool::approve function before calling _safe_tranfer_from function in TokenManager::withdraw.

} 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 12 months 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.