Closed c4-bot-10 closed 5 months ago
GalloDaSballo marked the issue as primary issue
GalloDaSballo marked the issue as sufficient quality report
The sponsor disputed the finding in some other dup, that said it does look valid for some tokens (which may not be the ones listed in scope)
The implementation is only behaving incorrectly when the token returns False
, in this case is should revert. When it does not return a valid, it reverts, or it returns True
, there is no impact.
The scope section defines:
ERC20 in scope: WETH, WBTC, LINK, DAI, WstETH, sDAI, USDC, USDT, WISE and may others in the future. (Also corresponding Aave tokens if existing)
None of the specified ERC20s in the list return False
on failure.
The question becomes whether the may others in the future
part of the scope description includes tokens with that behavior (which is fully compliant to the ERC20 spec).
It seems that the current implementation will brick the ability of the sponsor to insert other tokens in the future, at least that is a plausible scenario which achieves Med impact.
trust1995 marked the issue as satisfactory
trust1995 marked issue #245 as primary and marked this issue as a duplicate of 245
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/TransferHub/ApprovalHelper.sol#L7-L29 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/TransferHub/CallOptionalReturn.sol#L7-L38 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/TransferHub/TransferHelper.sol#L7-L51
Vulnerability details
Impact
CallOptionalReturn.sol
provides the_callOptionalReturn()
which is used to call a token contract, and return a boolean or revert based of the scenario. However it is done wrong.The above code is the content of the function however,
bool results
but is not checked here or where ever it is called.ApprovalHelper
is used to performsafeApprove()
call on tokens, however it misses something important.It does not check the bool being returned from the
_callOptionalReturn
TransferHelper
is used to perform_safeTransfer()
and_safeTransferFrom
call on tokens, however it misses something important also. It does not check the bool being returned from the_callOptionalReturn
Proof of Concept
From the EIP20 at https://eips.ethereum.org/EIPS/eip-20, it is stated that:
Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!
However, this is not handled here.Below is an ERC20 compliant token which tests the transfer functionality
The foundry output is as follows:
As we can see, it passes with no failure
Tools Used
Manual Review, Foundry, Remix, ENSReport
Recommended Mitigation Steps
Use OpenZeppelin's Safe ERC20 or add require statements to accurately check return value from
callOptionalReturn
Assessed type
ERC20