zkSync Era - mahdirostami's results

Future-proof zkEVM on the mission to scale freedom for all.

General Information

Platform: Code4rena

Start Date: 02/10/2023

Pot Size: $1,100,000 USDC

Total HM: 28

Participants: 64

Period: 21 days

Judge: GalloDaSballo

Total Solo HM: 13

Id: 292

League: ETH

zkSync

Findings Distribution

Researcher Performance

Rank: 47/64

Findings: 1

Award: $328.16

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: chaduke

Also found by: Aymen0909, HE1M, J4de, Nyx, Udsen, bart1e, bin2chen, chaduke, ladboy233, mahdirostami, rvierdiiev, tapir, zero-idea

Labels

bug
2 (Med Risk)
partial-50
sufficient quality report
duplicate-246

Awards

328.1628 USDC - $328.16

External Links

Lines of code

https://github.com/code-423n4/2023-10-zksync/blob/1fb4649b612fac7b4ee613df6f6b7d921ddd6b0d/code/contracts/ethereum/contracts/zksync/facets/Mailbox.sol#L261

Vulnerability details

Summary

The _verifyDepositLimit function is used to check if there is a deposit limit for ETH and ensures that users do not exceed their deposit limit. However, when the requestL2Transaction function is called by a bridge, it uses msg.sender as the user's address for the _verifyDepositLimit function, which is not appropriate (msg.sender is bridge).

 _verifyDepositLimit(msg.sender, msg.value);

Impact

This inconsistency in using msg.sender in the _verifyDepositLimit function can lead to the totalDepositedAmountPerUser variable increasing for bridges instead of users.

Tools Used

Manual review

Recommendations

To maintain consistency and ensure that the function operates as intended, consider using msg.origin instead of msg.sender when calling _verifyDepositLimit in the requestL2Transaction function:

 _verifyDepositLimit(msg.origin, msg.value);

This ensures that the deposit limit check is applied to the actual user rather than the bridge.

Assessed type

Invalid Validation

#0 - c4-pre-sort

2023-10-31T14:30:39Z

bytes032 marked the issue as duplicate of #246

#1 - c4-pre-sort

2023-10-31T14:30:50Z

bytes032 marked the issue as sufficient quality report

#2 - c4-judge

2023-11-24T19:25:39Z

GalloDaSballo marked the issue as partial-50

#3 - GalloDaSballo

2023-11-24T19:26:05Z

I think the lack of mention of the specific bridge contract to be a mistake that should be avoided for the contest

#4 - 0xmahdirostami

2023-11-30T03:41:53Z

@GalloDaSball, Thank you, sir, for the feedback, I'm not sure if it's convincing, but I thoroughly explained the situation, and its impact, and shared a revised code. Regarding the partial-50 assignment, I'm unsure of this specific case. Given the current state where only two bridges exist for WETH and ERC tokens, I assumed those are the relevant bridges.

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