Maia DAO - Ulysses - 0xblackskull's results

Harnessing the power of Arbitrum, Ulysses Omnichain specializes in Virtualized Liquidity Management.

General Information

Platform: Code4rena

Start Date: 22/09/2023

Pot Size: $100,000 USDC

Total HM: 15

Participants: 175

Period: 14 days

Judge: alcueca

Total Solo HM: 4

Id: 287

League: ETH

Maia DAO

Findings Distribution

Researcher Performance

Rank: 160/175

Findings: 1

Award: $0.11

🌟 Selected for report: 0

🚀 Solo Findings: 0

Lines of code

https://github.com/code-423n4/2023-09-maia/blob/main/src/VirtualAccount.sol#L85

Vulnerability details

Impact

When the PayableCall[] is not the msg.sender, payableCall() will be made on behalf of the msg.sender because no access control. As a result each of the functions called by payableCall() will be made on behalf of PayableCall[] target address. This can indeed lead to unexpected and potentially fund loss behaviour.

Proof of Concept

struct PayableCall {
    address target;
    bytes callData;
    uint256 value;
}

function payableCall(PayableCall[] calldata calls) public payable returns (bytes[] memory returnData) {
        uint256 valAccumulator;
        uint256 length = calls.length;
        returnData = new bytes[](length);
        PayableCall calldata _call;
        for (uint256 i = 0; i < length;) {
            _call = calls[i];
            uint256 val = _call.value;
            unchecked {
                valAccumulator += val;
            }

            bool success;

            if (isContract(_call.target)) (success, returnData[i]) = _call.target.call{value: val}(_call.callData);

            if (!success) revert CallFailed();

            unchecked {
                ++i;
            }
        }
        if (msg.value != valAccumulator) revert CallFailed();
    }

Tools Used

Manual code review

Use Modifier requiresApprovedCaller

Assessed type

Access Control

#0 - c4-pre-sort

2023-10-08T14:05:49Z

0xA5DF marked the issue as duplicate of #888

#1 - c4-pre-sort

2023-10-08T14:38:08Z

0xA5DF marked the issue as sufficient quality report

#2 - c4-judge

2023-10-26T11:29:34Z

alcueca marked the issue as satisfactory

#3 - c4-judge

2023-10-26T11:32:08Z

alcueca changed the severity to 3 (High Risk)

Lines of code

https://github.com/code-423n4/2023-09-maia/blob/main/src/VirtualAccount.sol#L85

Vulnerability details

Impact

Allowing anyone to trigger the payableCall() with an empty PayableCall[] array within a loop can indeed lead to a Denial of Service (DoS) attack. In this case an attacker repeatedly calls payableCall with an empty array within a loop, they can consume a significant amount of gas with each call, effectively causing a spike in transaction costs for the sender. If the attacker executes this attack repeatedly, it can lead to a situation where legitimate users are unable to afford the high gas costs required to interact with the contract, effectively denying service to legitimate users.

Proof of Concept

function payableCall(PayableCall[] calldata calls) public payable returns (bytes[] memory returnData) {
        uint256 valAccumulator;
        uint256 length = calls.length;
        returnData = new bytes[](length);
        PayableCall calldata _call;
        for (uint256 i = 0; i < length;) {
            _call = calls[i];
            uint256 val = _call.value;
            unchecked {
                valAccumulator += val;
            }

            bool success;

            if (isContract(_call.target)) (success, returnData[i]) = _call.target.call{value: val}(_call.callData);

            if (!success) revert CallFailed();

            unchecked {
                ++i;
            }
        }
        if (msg.value != valAccumulator) revert CallFailed();
    }

Tools Used

Manual code review

Use Modifier requiresApprovedCaller or check PayableCall[] is not empty

Assessed type

DoS

#0 - c4-pre-sort

2023-10-08T14:05:35Z

0xA5DF marked the issue as duplicate of #888

#1 - c4-pre-sort

2023-10-08T14:37:59Z

0xA5DF marked the issue as sufficient quality report

#2 - c4-judge

2023-10-26T11:29:31Z

alcueca marked the issue as satisfactory

#3 - c4-judge

2023-10-26T11:32:08Z

alcueca changed the severity to 3 (High Risk)

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter