Closed c4-submissions closed 10 months ago
141345 marked the issue as duplicate of #486
alex-ppg marked the issue as not a duplicate
alex-ppg marked the issue as duplicate of #739
alex-ppg marked the issue as satisfactory
alex-ppg changed the severity to 2 (Med Risk)
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/AuctionDemo.sol#L112
Vulnerability details
Impact
A malicious (or buggy) auction winner can refuse to accept the token and cause all bidders' funds to be locked in the
auctionDemo
contract. After the auction closes, the winner or admin can callclaimAuction
to initiate the transfer of the token to the winning bidder, the transfer of eth to the token owner, and the refunding of the losers bids. However, if the call tosafeTransferFrom
reverts for some reason (e.g. a maliciousonERC721Received
handler), thenclaimAuction
will revert and all the funds will be locked in theauctionDemo
contract. After the auction ends there is no other mechanism for funds to be transferred from the contract.Proof of Concept
The call to
IERC721(gencore).safeTransferFrom
in L112 can revert. A malicious winner can lock the funds asclaimAuction
is also responsible for refunding losing bids:safeTransferFrom
will eventually call_safeTransfer
in ERC721.sol:If
_checkOnERC721Received
returns false or reverts, then the transfer will revert:A malicious winner could easily force this condition via the
onERC721Received
PoC Tests
Create
test/AuctionDemoMaliciousWinner.t.sol
and runforge test --match-test test_attackerDeniesLosingBidRefunds
.Tools Used
VScode. Foundry
Recommended Mitigation Steps
Execute the
safeTransferFrom
in a try statement. If it reverts, then refund the winner (don't pay the token owner as the token isn't transferred) and continue to refund the losers.The below diff fixes the issue:
Assessed type
Token-Transfer