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

underSpentAmount should be transferred back to sender without any fee. #47

Closed
code423n4 opened this issue Jun 18, 2022 · 3 comments
Closed
Assignees
Labels
bug Something isn't working invalid This doesn't seem right QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-06-nested/blob/b4a153c943d54755711a2f7b80cbbf3a5bb49d76/contracts/NestedFactory.sol#L486-L505

Vulnerability details

Impact

underSpentAmount is dust amount, Currently, fee is even applied to dust amount, causing overspent user to loss some money due to this fee. Normally, dust amount must transfer back to only _msgSender() as a best practice without any fee applied to it.

Proof of Concept

            require(amounts[1] <= _amountToSpend, "NF: OVERSPENT");
            unchecked {
                uint256 underSpentAmount = _amountToSpend - amounts[1];
                if (underSpentAmount != 0) {
                    _safeTransferWithFees(IERC20(_inputToken), underSpentAmount, _msgSender(), _nftId);
                }
            }

You will see that you are correcting fee transferring underSpentAmount back to _msgSender().

Since these underSpentAmount is not being used, it should be transferred back without any fee.

Tools Used

Manual

Recommended Mitigation Steps

You should transfer dust amount back to sender without any fee

            require(amounts[1] <= _amountToSpend, "NF: OVERSPENT");
            unchecked {
                uint256 underSpentAmount = _amountToSpend - amounts[1];
                if (underSpentAmount != 0) {
                    SafeERC20.safeTransfer(IERC20(_inputToken), _msgSender(), underSpentAmount);
                }
            }
@code423n4 code423n4 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 Jun 18, 2022
code423n4 added a commit that referenced this issue Jun 18, 2022
@Yashiru Yashiru self-assigned this Jun 20, 2022
@obatirou
Copy link
Collaborator

underSpentAmount should be transferred back to sender without any fee. (disputed)

When we return the dust to the msgSender, we do the equivalent of a withdraw from the NestedReserve to the msgSender, so we must apply the fees corresponding to this withdrawal.

@obatirou obatirou added the sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue label Jun 23, 2022
@jack-the-pug
Copy link
Collaborator

It's a best practice/suggestion, I'll downgrade it to QA.

@jack-the-pug jack-the-pug added QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax valid and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Jul 12, 2022
@JeeberC4 JeeberC4 added the duplicate This issue or pull request already exists label Jul 14, 2022
@jack-the-pug
Copy link
Collaborator

This is indeed a misunderstanding of the design. I was wrong about this being a valid suggestion. It should be invalid.

The underSpentAmount is actually the amount that can not be converted to _buyToken (should be a dust amount in most cases, though), and the exitFee should be applied to this.

In the meantime, applying the exitFee onto the outputToken of the swap makes it possible for the users to bypass the exitFee by using malicious payloads for the swap. See #69.

@jack-the-pug jack-the-pug added invalid This doesn't seem right and removed valid duplicate This issue or pull request already exists labels Aug 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working invalid This doesn't seem right QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax sponsor disputed Sponsor cannot duplicate the issue, or otherwise disagrees this is an issue
Projects
None yet
Development

No branches or pull requests

5 participants