Maia DAO - Ulysses - Inspecktor'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: 82/175

Findings: 2

Award: $25.79

QA:
grade-a

🌟 Selected for report: 0

🚀 Solo Findings: 0

Lines of code

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

Vulnerability details

Proof of Concept

Function VirtualAccount.payableCall() (https://github.com/code-423n4/2023-09-maia/blob/main/src/VirtualAccount.sol#L85-L112) aggregate calls ensuring each call is successful. The contract has a similar function for a single call call() (https://github.com/code-423n4/2023-09-maia/blob/main/src/VirtualAccount.sol#L66). This function has a modifier requiresApprovedCaller, which checks that the calling address is approved.

The VirtualAccount.payableCall() function is missing access check modifiers. It is a public function. It can be called by an attacker.

The input parameters of the VirtualAccount.payableCall() function are PayableCall[] calldata calls.

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

Those. an attacker can control the low-level call in terms of target and callData. This vulnerability can lead to the theft of funds from a contract by sending them to any target address.

Tools Used

Manual review

Check access to the VirtualAccount.payableCall() function with at least the modifier requiresApprovedCaller

Assessed type

call/delegatecall

#0 - c4-pre-sort

2023-10-08T14:00:57Z

0xA5DF marked the issue as duplicate of #888

#1 - c4-pre-sort

2023-10-08T14:38:32Z

0xA5DF marked the issue as sufficient quality report

#2 - c4-judge

2023-10-26T11:28:27Z

alcueca marked the issue as satisfactory

Lines of code

https://github.com/code-423n4/2023-09-maia/blob/main/src/BranchPort.sol#L144-L164 https://github.com/code-423n4/2023-09-maia/blob/main/src/BranchPort.sol#L167-L185

Vulnerability details

Proof of Concept

BranchPort.manage() (https://github.com/code-423n4/2023-09-maia/blob/main/src/BranchPort.sol#L144-L164) - allows active Port Strategy addresses to withdraw assets. The function includes checking the daily limit of the port strategy.

BranchPort.replenishReserves() (https://github.com/code-423n4/2023-09-maia/blob/main/src/BranchPort.sol#L167-L185) - allow approved address to repay borrowed reserves.

However, when the user calls BranchPort.manage(), the amount amount is subtracted from the daily limit: strategyDailyLimitRemaining[msg.sender][_token] = dailyLimit - _amount;

But, when the user calls BranchPort.replenishReserves() the amount returned is not added to the daily limit.

This is not true. When the user wants to call BranchPort.manage() again with an amount less than the daily limit plus the amount of funds redeemed today, he will not be able to do so. Although formally the daily limit has not been exceeded.

Tools Used

Manual review

Add the repaid amount to the daily limit

Assessed type

Context

#0 - c4-pre-sort

2023-10-08T06:01:08Z

0xA5DF marked the issue as primary issue

#1 - 0xA5DF

2023-10-08T06:01:18Z

Seems like intended design, but leaving open for sponsor to comment

#2 - c4-pre-sort

2023-10-08T14:46:45Z

0xA5DF marked the issue as sufficient quality report

#3 - c4-pre-sort

2023-10-12T16:14:17Z

0xA5DF marked the issue as duplicate of #694

#4 - c4-judge

2023-10-26T09:18:46Z

alcueca changed the severity to QA (Quality Assurance)

#5 - c4-judge

2023-10-26T09:19:08Z

alcueca marked the issue as grade-b

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