Closed c4-submissions closed 10 months ago
141345 marked the issue as duplicate of #1952
alex-ppg marked the issue as duplicate of #2038
alex-ppg marked the issue as unsatisfactory: Out of scope
alex-ppg marked the issue as unsatisfactory: Out of scope
Lines of code
https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/MinterContract.sol#L276 https://github.com/code-423n4/2023-10-nextgen/blob/main/hardhat/smart-contracts/AuctionDemo.sol#L57
Vulnerability details
Bug Description
mintAndAuction()
in MinterContract.sol airdrops a token and starts an auction. Bidders participate viaparticipateToAuction()
in AuctionDemo.sol. Neither function sets a minimum starting price for the auction or a minimum percentage price increase for each high bid. Bids can increase by 1 wei, all that is required is that the auction is started and the current bid is higher than the last bid.MinterContract.sol lines 276-298
AuctionDemo.sol lines 57-61
An attacker can enter the bidding just after
mintAndAuction()
and make thousands of bids with very small increments (1 wei). It costs them 1 wei + gas but it results in thousands of small bids being added toauctionInfoData
in AuctionDemo.sol.These low bids will eventually be cost prohibitive for the attacker as soon as a legitimate bidder adds a realistic bid however they are still stored in the bid array waiting to break
claimAuction
.The issue comes when the highest bidder calls
claimAuction()
. It iterates through all the bids to find the highest bidder and highest bid price. With a large number of low attacker bids this will consume all available gas and revert. Breaking the ability to claim the token, transfer funds to the auctioned token owner and refund valid bids.Impact
An attacker can grief the platform for minimal cost, backrunning each auction and adding enough low bids to ensure it can't be claimed. The protocol admins would need to manually transfer tokens and ETH to the auction winner, the token owner and all legitimate bidders in the auction by hand.
The NextGen platform would suffer reputational damage as each auction is griefed and they have no ability to response to the attack vector without upgrading contracts or minting tokens for auction on another platform by hand.
Gas price becomes the only economic disincentive for the attacker however it is likely that popular mints will still be griefed, even if gas per transaction was moderately high.
Proof of Concept
In
test_BidGriefing
the attacker backruns the mint and adds 2000 bids that are 1 wei above their previous bid. This costs them 2,001,000 wei but allows them to push the gas cost ofclaimAuction()
above 30 million wei.The test can be run in multiple ways;
Firstly to show it reverts at 30 million wei;
forge test --match-test test_BidGriefing -vv --fork-url=$GOERLI --via-ir --gas-limit 30000000
Or to see the gas amount for
claimAuction()
if the attacker uses 2000 iterations.forge test --match-test test_BidGriefing -vv --fork-url=$GOERLI --via-ir --gas-report
With 2,000 iterations
claimAuction()
consumes30337233
gas.Tools Used
Vim
Recommended Mitigation Steps
NextGen should allow a reserve to be set and that each bid is not only higher but a percentage increase on the bid before. This is a technique that both Superrare and Foundation use for auctions.
Assessed type
DoS