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

Lack of success check for low level call could make swapAndExecute(...) function fail silently #564

Closed
c4-bot-7 opened this issue Jan 23, 2024 · 5 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-641 insufficient quality report This report is not of sufficient quality unsatisfactory does not satisfy C4 submission criteria; not eligible for awards

Comments

@c4-bot-7
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2024-01-decent/blob/011f62059f3a0b1f3577c8ccd1140f0cf3e7bb29/src/UTBExecutor.sol#L70

Vulnerability details

Impact

Loss of funds to the user

Scenario

  1. Alice calls swapAndExecute to execute a transaction with 1000 ERC20 tokens
  2. The target contract is takes the ERC20 token but the transaction fails
  3. Because the returned bool value is not checked, the transaction did not revert causing user to lose the 1000 ERC20 tokens.

Proof of Concept

The UTBExecutor.excute(...) function is used to execute calls in the UTB.sol#swapAndExecute(...) function.

In a situation where the call on line 70 fails, the transaction may will not revert because the boolean returned value was asigned but not checked to revert if it's false.

File: UTBExecutor.sol
function execute(
        address target,
        address paymentOperator,
        bytes memory payload,
        address token,
        uint amount,
        address payable refund,
        uint extraNative
    ) public onlyOwner {
        bool success;
        if (token == address(0)) {
            (success, ) = target.call{value: amount}(payload);
            if (!success) {
                (refund.call{value: amount}(""));
            }
            return;
        }

        uint initBalance = IERC20(token).balanceOf(address(this));

        IERC20(token).transferFrom(msg.sender, address(this), amount);
        IERC20(token).approve(paymentOperator, amount);

        if (extraNative > 0) {
            (success, ) = target.call{value: extraNative}(payload);
            if (!success) {
                (refund.call{value: extraNative}(""));//@audit revert early.
            }
        } else {
@>            (success, ) = target.call(payload);//@audit success not checked.
        }

        uint remainingBalance = IERC20(token).balanceOf(address(this)) -
            initBalance;

        if (remainingBalance == 0) {
            return;
        }

        IERC20(token).transfer(refund, remainingBalance);
    }

Tools Used

Manual review

Recommended Mitigation Steps

Consider checking the returned bool value from an address.call

(success, ) = target.call(payload);
require(success, "execution failed");

Assessed type

call/delegatecall

@c4-bot-7 c4-bot-7 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 Jan 23, 2024
c4-bot-7 added a commit that referenced this issue Jan 23, 2024
@c4-pre-sort
Copy link

raymondfam marked the issue as insufficient quality report

@c4-pre-sort c4-pre-sort added the insufficient quality report This report is not of sufficient quality label Jan 25, 2024
@c4-pre-sort
Copy link

raymondfam marked the issue as duplicate of #70

@c4-judge
Copy link

c4-judge commented Feb 2, 2024

alex-ppg marked the issue as not a duplicate

@c4-judge c4-judge reopened this Feb 2, 2024
@c4-judge c4-judge closed this as completed Feb 2, 2024
@c4-judge
Copy link

c4-judge commented Feb 2, 2024

alex-ppg marked the issue as duplicate of #641

@c4-judge
Copy link

c4-judge commented Feb 2, 2024

alex-ppg marked the issue as unsatisfactory:
Invalid

@c4-judge c4-judge added the unsatisfactory does not satisfy C4 submission criteria; not eligible for awards label Feb 2, 2024
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-641 insufficient quality report This report is not of sufficient quality unsatisfactory does not satisfy C4 submission criteria; not eligible for awards
Projects
None yet
Development

No branches or pull requests

3 participants