Contracts are vulnerable to fee-on-transfer accounting-related issues
code423n4 opened this issue · 1 comments
Lines of code
359, 448, 509, 530, 42, 797, 162
Vulnerability details
The functions below transfer funds from the caller to the receiver via transferFrom()
, but do not ensure that the actual number of tokens received is the same as the input amount to the transfer. If the token is a fee-on-transfer token, the balance after the transfer will be smaller than expected, leading to accounting issues. Even if there are checks later, related to a secondary transfer, an attacker may be able to use latent funds (e.g. mistakenly sent by another user) in order to get a free credit. One way to solve this problem is to measure the balance before and after the transfer, and use the difference as the amount, rather than the stated amount.
File: contracts/tOFT/BaseTOFT.sol
359: IERC20(erc20).safeTransferFrom(_fromAddress, address(this), _amount);
File: contracts/governance/twTAP.sol
448: rewardToken.safeTransferFrom(msg.sender, address(this), _amount);
File: contracts/option-airdrop/AirdropBroker.sol
509 _paymentToken.transferFrom(
510 msg.sender,
511 address(this),
512 discountedPaymentAmount
513: );
File: contracts/options/TapiocaOptionBroker.sol
530 _paymentToken.transferFrom(
531 msg.sender,
532 address(this),
533 discountedPaymentAmount
534: );
File: contracts/tokens/LTap.sol
42: tapToken.transferFrom(msg.sender, address(this), amount);
File: contracts/Magnetar/modules/MagnetarMarketModule.sol
797: IERC20(_token).safeTransferFrom(_from, address(this), _amount);
File: contracts/Swapper/BaseSwapper.sol
162: IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
Assessed type
other
@geoffchan23 Sponsors are not allowed to close, reopen, or assign issues or pull requests.