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

Shaheen - _refundExcess() Functionality will Never Work and Users will Loose Ethers as the Funds will be Stuck in the FeeManager Contract #351

Closed
sherlock-admin4 opened this issue Apr 26, 2024 · 5 comments
Labels
Duplicate A valid issue that is a duplicate of an issue with `Has Duplicates` label Escalation Resolved This issue's escalations have been approved/rejected Medium A valid Medium severity issue Reward A payout will be made for this issue

Comments

@sherlock-admin4
Copy link
Contributor

sherlock-admin4 commented Apr 26, 2024

Shaheen

medium

_refundExcess() Functionality will Never Work and Users will Loose Ethers as the Funds will be Stuck in the FeeManager Contract

Summary

_refundExcess() will never work and users will loose ethers as the funds will be stuck in the FeeManager contract (temporarily)

Vulnerability Detail

The refundExcess() function is called after minting tokens to refund any ETH left in the contract after all fees have been collected. As we can see, this function transfers the Edition contract's balance to the user (of course when expected):

    function _refundExcess() internal {
        if (msg.value > 0 && address(this).balance > 0) {
            msg.sender.safeTransferETH(address(this).balance);
        }
    }

To understand the vulnerablity, we need to look at one of the minting functions. There are four minting functions, all utilizing refundexcess() mint(), mintWithComment() & both mintBatch() functions. Let's take only mintWithComment() to undertand the issue:

    function mintWithComment(address to_, uint256 tokenId_, uint256 amount_, address referrer_, bytes calldata data_, string calldata comment_) external payable {
        Strategy memory strategy = works[tokenId_].strategy;
        FEE_MANAGER.collectMintFee{value: msg.value}(this, tokenId_, amount_, msg.sender, referrer_, strategy);
        _issue(to_, tokenId_, amount_, data_);
        _refundExcess();
        emit Comment(address(this), tokenId_, to_, comment_);
    }

As we can see, the mintWithComment() function, first calls the FeeManager's collectMintFee() function, which calculates and takes the fee from the user), then it calls the _issue() function, which mints an NFT to the user and then the _refundExcess() function will called to return the excess amount to the user.

Issue

The problem is, that when the mintWithcomment() function calls the collectMintFee(), it gives all the msg.value to the FeeManager contract. But the FeeManager contract never returns it back to the Edition contract, which means all the excess fee will be stuck in the FeeManager contract and users will never get any excess amount back as the the refundExcess() function only checks and transfers Editions Contracts balance.

Proof-of-Concept

    function test_mintAndRefundExcessFee_PoC() public {
        vm.deal(address(5), 1.0106 ether);
        assertEq(address(feeManager).balance, 0);

        vm.prank(address(5));
        edition.mint{value: 1.0106 ether}(address(1), 1, 1, address(0), new bytes(0));

        assertEq(edition.totalSupply(1), 1);
        assertEq(address(5).balance, 0); //> No Refund
        assertEq(address(1).balance, 0.01 ether);
        assertEq(address(0xc0ffee).balance, 0.0006 ether);
        assertEq(address(feeManager).balance, 1 ether); //> Excess fee Stuck in FeeManager 
    }

Impact

  • Loss of funds for the users
  • Broken functionality of the protocol
  • Temporary freezing of the funds

Code Snippet

https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L514
https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L236

Tool used

Eyes

Recommendation

Make sure that the FeeManager contracts returns the excess fee amount to the Edition contract.

Duplicate of #269

@github-actions github-actions bot closed this as completed May 6, 2024
@github-actions github-actions bot added the Excluded Excluded by the judge without consulting the protocol or the senior label May 6, 2024
@sherlock-admin2 sherlock-admin2 changed the title Able Velvet Lobster - _refundExcess() Functionality will Never Work and Users will Loose Ethers as the Funds will be Stuck in the FeeManager Contract Shaheen - _refundExcess() Functionality will Never Work and Users will Loose Ethers as the Funds will be Stuck in the FeeManager Contract May 12, 2024
@sherlock-admin2 sherlock-admin2 added the Non-Reward This issue will not receive a payout label May 12, 2024
@ShaheenRehman
Copy link

Escalate

Judge Sahab! This finding is a valid dup of #269, In fact this Watson added a coded PoC as well. Thanks!

@sherlock-admin3
Copy link
Contributor

Escalate

Judge Sahab! This finding is a valid dup of #269, In fact this Watson added a coded PoC as well. Thanks!

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

@sherlock-admin4 sherlock-admin4 added the Escalated This issue contains a pending escalation label May 13, 2024
@WangSecurity
Copy link
Collaborator

Agree with the escalation, planning to accept and duplicate with #269

@Evert0x Evert0x added the Medium A valid Medium severity issue label May 18, 2024
@sherlock-admin2 sherlock-admin2 added Reward A payout will be made for this issue and removed Non-Reward This issue will not receive a payout labels May 18, 2024
@Evert0x Evert0x added High A valid High severity issue and removed Medium A valid Medium severity issue labels May 18, 2024
@Evert0x
Copy link

Evert0x commented May 18, 2024

Result:
High
Duplicate of #269

@sherlock-admin2 sherlock-admin2 removed the Escalated This issue contains a pending escalation label May 18, 2024
@sherlock-admin3 sherlock-admin3 added the Escalation Resolved This issue's escalations have been approved/rejected label May 18, 2024
@sherlock-admin4
Copy link
Contributor Author

Escalations have been resolved successfully!

Escalation status:

@WangSecurity WangSecurity added Medium A valid Medium severity issue and removed High A valid High severity issue labels May 26, 2024
@sherlock-admin2 sherlock-admin2 added Duplicate A valid issue that is a duplicate of an issue with `Has Duplicates` label and removed Excluded Excluded by the judge without consulting the protocol or the senior labels May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate A valid issue that is a duplicate of an issue with `Has Duplicates` label Escalation Resolved This issue's escalations have been approved/rejected Medium A valid Medium severity issue Reward A payout will be made for this issue
Projects
None yet
Development

No branches or pull requests

6 participants