search

code-423n4 / 2024-03-zksync-findings

2 stars 1 forks source link

QA Report #90

Open c4-bot-5 opened 8 months ago

c4-bot-5 commented 8 months ago

See the markdown file with the details of this report here.

c4-sponsor commented 7 months ago

razzorsec (sponsor) acknowledged

razzorsec commented 7 months ago

We acknowledge some of the findings, and we want to make comments for them as: L01 => sort of true, but the situation is unreal (the current system does not support arbitrary turning off/on of hyperbridging, what more, even turning on is not supported) L06 => looks legit, but changing governance is hard, so unless there is a specific bug, we wont change N01 => Design Choice N02 => Expected

c4-judge commented 7 months ago

alex-ppg marked the issue as grade-b

0xSorryNotSorry commented 7 months ago

Thank you so much for judging this large codebase and spending more time looking into this escalation again @alex-ppg ,

The contest page declares below (At the first paragraph of this section):

While the assumption is that either governance or security council are not malicious, neither governance, nor the security council should be able to circumvent the limitations imposed on them.

We believe that our L-05 Issue breaks above declaration circumventing the limitations with a valid path.

Looking forward to your consideration for upgrading it to Med.

Thank you again.

alex-ppg commented 7 months ago

Hey @0xSorryNotSorry, thanks for contributing to the PJQA process! The owner has more privileges than the securityCouncil by the system's design; the only party able to propose is the owner. The only way to adjust the security council is for a proposal to go through, either instantaneously or via a normal delay. Only the owner is able to cancel proposals which is a deliberate change per the contest's Changelog.

Culminating the above, only the owner is able to change the security council and the security council can only execute proposals the owner has specified and cannot act independently. As such, issue L-05 outlines a valid QA / Analysis observation that the owner has more privileges than the security council but does not outline an actual vulnerability or misbehavior of the code.

If the security council was able to cancel proposals, then I would deem this a correct M vulnerability but that would also open up an attack vector whereby the security council holds the owner hostage, which is a scenario I presume the zkSync Era team wanted to avoid in the first place.