When these sorts of tokens that do not return booleans as the specification requires, and instead have no return value are cast to IERC20, their function signatures do not match and therefore the calls made, revert.
Proof of Concept
Some tokens do not implement the ERC20 standard properly but are still accepted by most code that accepts ERC20 tokens. For example Tether (USDT)'s transfer() and transferFrom() functions on L1 do not return booleans as the specification requires, and instead have no return value. When these sorts of tokens are cast to IERC20, their function signatures do not match and therefore the calls made, revert.
Tools Used
Visual Studio Code
Recommended Mitigation Steps
Use OpenZeppelin’s SafeERC20's safeTransfer()/safeTransferFrom() instead
Lines of code
https://github.com/code-423n4/2023-06-stader/blob/main/contracts/Auction.sol#L87 https://github.com/code-423n4/2023-06-stader/blob/main/contracts/Auction.sol#L55
Vulnerability details
Impact
When these sorts of tokens that do not return booleans as the specification requires, and instead have no return value are cast to IERC20, their function signatures do not match and therefore the calls made, revert.
Proof of Concept
Some tokens do not implement the ERC20 standard properly but are still accepted by most code that accepts ERC20 tokens. For example Tether (USDT)'s transfer() and transferFrom() functions on L1 do not return booleans as the specification requires, and instead have no return value. When these sorts of tokens are cast to IERC20, their function signatures do not match and therefore the calls made, revert.
Tools Used
Visual Studio Code
Recommended Mitigation Steps
Use OpenZeppelin’s SafeERC20's safeTransfer()/safeTransferFrom() instead
Assessed type
Token-Transfer