When a user attempts to withdraw tokens other than WETH, the withdrawal process fails due to the absence of an approve
function call. This leads to an ERC20InsufficientAllowance
error.
The vulnerability lies in the fact that the approve
function is not implemented when withdrawing tokens other than WETH. As a result, when a user tries to withdraw any ERC20 token other than WETH, they encounter an ERC20InsufficientAllowance
error, causing the withdrawal to fail. This issue is evident in the TokenManager::
withdraw function:
The function directly attempts to transfer tokens without calling approve
,which is necessary for the CapitalPool
to transfer the tokens.
Users are unable to withdraw/claim ERC20 tokens due to insufficient allowance .
Manual Code Review
Foundry
Implement the approve
function for ERC20 tokens as it has been implemented for wrappedNativeToken
.
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
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.