Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Highest bid is sent to wrong owner in claimAuction #1557

Closed
c4-submissions opened this issue Nov 13, 2023 · 2 comments
Closed

Highest bid is sent to wrong owner in claimAuction #1557

c4-submissions opened this issue Nov 13, 2023 · 2 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate-971 satisfactory satisfies C4 submission criteria; eligible for awards

Comments

@c4-submissions
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/AuctionDemo.sol#L113-L114
https://github.com/code-423n4/2023-10-nextgen/blob/8b518196629faa37eae39736837b24926fd3c07c/smart-contracts/AuctionDemo.sol#L18

Vulnerability details

Impact

In Attack Ideas there is:

"Consider ways in which the owner of the token will not receive the funds of the highest bid after an Auction is claimed."

This makes it clear that expected behavior of the AuctionDemo.claimAuction function is to send highest bid to the owner of the auctioned token.

However, highest bid is sent to the owner of the AuctionDemo contract instead (AuctionDemo inherits from Ownable).

So if the owner of the contract is different from the owner of the token, then highest bid is sent to wrong address.

Proof of Concept

Full code to and exact steps to reproduce the issue are in this secret gist.

Here is only test that demonstrates the issue (without setup):

    function testWrongOwner() public {
        // get id of of the auctioned token
        uint256 tokenId = gencore.viewTokensIndexMin(collectionId);

        // check initial state
        assertEq(gencore.ownerOf(tokenId), nftOwner);
        assertEq(auction.owner(), auctionOwner);

        // Ownabele owner of the contract
        // and owner of the auction tokenId
        // are two different addresses
        assertTrue((auctionOwner != nftOwner));
        assertEq(auctionOwner.balance, 0);
        assertEq(nftOwner.balance, 0);

        // required approval so that claimAuction won't revert
        vm.prank(nftOwner);
        gencore.approve(address(auction), tokenId);

        // user1 participates in the acution
        vm.prank(user1);
        auction.participateToAuction{value: 1 ether}(tokenId);

        // user2 wins the auction
        vm.prank(user2);
        auction.participateToAuction{value: 2 ether}(tokenId);

        // wait until claimAuction available
        vm.warp(minter.getAuctionEndTime(tokenId) + 12);

        // call claimAuction
        vm.prank(user2);
        auction.claimAuction(tokenId);

        // check final state
        assertEq(gencore.ownerOf(tokenId), user2);
        assertEq(auction.owner(), auctionOwner);

        // Verify that ETH was sent to auctionOwner, not nftOwner
        assertTrue((auctionOwner != nftOwner));
        assertEq(auctionOwner.balance, 2 ether);
        assertEq(nftOwner.balance, 0);
    }

Tools Used

Foundry, manual analysis

Recommended Mitigation Steps

Change owner() to ownerOfToken in AuctionDemo.claimAuction function.

Assessed type

Other

@c4-submissions c4-submissions added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Nov 13, 2023
c4-submissions added a commit that referenced this issue Nov 13, 2023
@c4-pre-sort
Copy link

141345 marked the issue as duplicate of #245

@c4-judge c4-judge added duplicate-738 satisfactory satisfies C4 submission criteria; eligible for awards and removed duplicate-245 labels Dec 5, 2023
@c4-judge
Copy link

c4-judge commented Dec 8, 2023

alex-ppg marked the issue as satisfactory

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate-971 satisfactory satisfies C4 submission criteria; eligible for awards
Projects
None yet
Development

No branches or pull requests

3 participants