Open hats-bug-reporter[bot] opened 1 month ago
Thank you for your report on the potential unsafe use of transferFrom() in the Migration Contract. After careful review, we've determined that this is not an issue.
The transferFrom() function is called on CirclesV1 tokens, which correctly implement the ERC20 standard. This implementation ensures that the function behaves as expected and does not cause any problems within our system.
We appreciate your attention to potential security vulnerabilities in our contract interactions. Your diligence in examining our code contributes to the overall robustness of our platform. Thank you for your efforts in helping ensure the security of our system.
@benjaminbollen I would like to escalate this issue, again as I feel it is perfectly valid I believe this issue deserves reconsideration for the following reasons.
Not all ERC20 tokens follow the standard correctly, and some (like USDT) don't return booleans for transfers.
The current implementation could lead to silent failures and state inconsistencies if a transfer fails.
Using OpenZeppelinn provides SafeERC20 specifically to address these concerns.
Implementing the fix is straightforward and significantly improves the contract's robustness with minimal downsides.
@Naties29 it's clearly using ONLY CircleV1 token, not any other ERC20 or USDT
@kakarottosama Thank you for clarifying!
Github username: -- Twitter username: -- Submission hash (on-chain): 0x25a3341ce9c3658eb0cc5154469dbe196af078867c309a74bc35a888a082afe2 Severity: low
Description:
Description
The
Migration
contract, responsible for migrating tokens from Circles v1 to v2, contains a potential vulnerability due to the unsafe use of thetransferFrom()
function. This issue is present in themigrate()
function, which is central to the token migration process.The vulnerability stems from the lack of proper error handling when calling
transferFrom()
. The function does not check the return value of the transfer operation, nor does it use a safe transfer method. This can lead to silent failures during the migration process, potentially resulting in a mismatch between v1 tokens transferred and v2 tokens minted.Location:
Migration
contract,migrate()
functionPotential Consequences
If SafeTransfer is not implemented, several issues could arise:
Silent Failures:
Token Loss:
Inconsistent Contract State:
Vulnerability to Non-Standard ERC20 Implementations:
transfer
andtransferFrom
.1. Proof of Concept
This PoC showcases the existing vulnerable code in the
Migration
contract. The issue is in themigrate()
function, specifically the line:This line uses the unsafe
transferFrom()
method without checking its return value or using a safe transfer method, which can lead to silent failures and the potential consequences described above.2. Revised Code File
Explanation of the fix:
SafeERC20
library at the top of the contract.using SafeERC20 for IERC20;
statement to enable the use of safe transfer functions.migrate()
function, we replace the unsafetransferFrom()
call withsafeTransferFrom()
:This change ensures that:
By implementing this fix, we improve the security and reliability of the migration process. Any transfer failure will now cause the entire transaction to revert, preventing inconsistencies between v1 token transfers and v2 token minting.