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

Incorrect usage of _safe_transfer_from

Audittens

Summary

When withdrawing an ERC-20 token from TokenManager, the TokenManager calls _safe_transfer_from, which depends on the allowance of _token. If the allowance is not set, the call will fail, leading to a freeze of funds/ broken logic.

Vulnerability Details

When a user tries to withdraw ERC-20 (that is not wrapped native currency, which is handled differently) _token from CapitalPool he will call withdraw function in TokenManager. The withdraw handles ERC-20 tokens in lines 171-180, as shown below:

/**
* @dev token is ERC20 token
* @dev transfer from capital pool to msg sender
*/
_safe_transfer_from(
_tokenAddress,
capitalPoolAddr,
_msgSender(),
claimAbleAmount
);

As we can see, it calls _safe_transfer_from, which in it's turn relies on TokenManager having allowance for using token on behalf of CapitalPool:

/**
* @dev Safe transfer.
* @param token The token to transfer. If 0, it is ether.
* @param to The address of the account to transfer to.
* @param amount The amount to transfer.
*/
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();
}
}

This means that if allowance for TokenManager isn't set, the call will fail, and and users will not be able to use the withdraw function.

Impact

The impact depends on how another issue in the code will be addressed.
There is a function approve in CapitalPool:

/**
* @dev Approve token for token manager
* @notice only can be called by token manager
* @param tokenAddr address of token
*/
function approve(address tokenAddr) external {
address tokenManager = tadleFactory.relatedContracts(
RelatedContractLibraries.TOKEN_MANAGER
);
(bool success, ) = tokenAddr.call(
abi.encodeWithSelector(
APPROVE_SELECTOR,
tokenManager,
type(uint256).max
)
);
​
if (!success) {
revert ApproveFailed();
}
}

According to the comment, the function should only be callable by TokenManager.
I will discuss both cases: if the approve function is fixed according to the comment, and if it is not.

  1. The approve gets fixed, and is only callable by TokenManager. In this case, the funds are frozen in CapitalPool, as no one can set the allowance for TokenManager. The only way to unfreeze them is to call _transfer in TokenManager, which is transferring token _token from CapitalPool. The _transfer function calls approve on CapitalPool, so the allowance will be set, and the transfer will go through.

  2. The approve doesn't get fixed, and is callable by anyone. In this case, the funds are temporary frozen in CapitalPool, until someone calls approve(_token) on CapitalPool, or, same as in case 1, _transfer(_token) will be called.

Tools Used

Manual Review

Recommendations

Change _safe_transfer_from to _transfer on L175 in TokenManager.

/**
* @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 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.