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

Traders may fail to withdraw funds for some special tokens which return false if transferring faliure.

jennifersun

Summary

The implementation of function _safe_transfer_from() is not safe. We will not revert if the tranferFrom() return value is false.

Vulnerability Details

In readme, the sponsor mentions that the Tadle protocol is designed for any EVM, any ERC20 Tokens that follows the ERC20 standard.
In EIP20 standard, https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md, the description mentions: Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!. So tokens which transfer()/transferFrom() return false follow ERC20 standard.
In withdraw(), when traders withdraw non-native tokens, we will call _safe_transfer_from() function. What's more, we don't check whether there is enough allowance to transfer from capitalPool to the trader.
The problem is generated because of the two vulnerability.

  1. In withdraw(), we don't check the allowance, and don't to call ICapitalPool(_capitalPoolAddr).approve(). We should assume that the trader can call withdraw() function directly to get the funds. If anyone does not call ICapitalPool(_capitalPoolAddr).approve(token) directly, the allowance approved is 0.

  2. _safe_transfer_from() will not reverted if the allowance is not enough for some tokens, for example: ZRX, EURS.

If the trader wants to withdraw ZRX from the capitalPool, and we don't trigger approve, the withdraw() operation will be finished and the trader will get 0 amount.

function withdraw(
address _tokenAddress,
TokenBalanceType _tokenBalanceType
) external whenNotPaused {
......
​
if (_tokenAddress == wrappedNativeToken) {
......
} else {
_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

The traders may lose funds when traders withdraw ZRX/EURS from capitalPool.

Tools Used

Manual

Recommendations

The function _transfer() process this case smoothly. Consider to replace _safe_transfer_from() in withdraw() function by _transfer().
In _transfer(), if the allowance is 0, we will trigger approve to make everything correct.

Updates

Lead Judging Commences

0xnevi Lead Judge over 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.

Give us feedback!