Severity standardization - event related impacts

[trust1995]

It would be beneficial for all of us to standardize severities for common issues. This discussion is regarding incorrect emission of events, for example with wrong parameters, flows where an event is emitted incorrectly or not emitted when it should be, etc.

Typically reports of that sort are graded QA. Examples of past severities: https://github.com/code-423n4/2022-10-holograph-findings/issues/270 - M https://github.com/code-423n4/2022-11-redactedcartel-findings/issues/334 - QA https://github.com/code-423n4/2022-10-juicebox-findings/issues/80 - QA

In my opinion, unless warden can show clear reasoning why this event is important for functionality of some pre-discussed off-chain setup, it should be marked as QA. For example, will not display auction in UI, etc.

[dmvt]

I agree that events should almost always be QA. I'm having a hard time thinking of a scenario where that would not be the case.

[GalloDaSballo]

Unless the event is provably used in explicitly:

• In scope code
• Known code (stated in Readme / Dependencies)

Then the maximum impact of an event will always be Informational, even when there's typos, mistakes, etc..

Sometimes such a finding may want to be rewarded (internal points / QA scoring), but in terms of severity, the severity has got to be Non-Critical / Informational by definition (unless the point above can be made convincingly)

[akshaysrivastav]

There could be cases where incorrect event emission or incorrect event data can be impactful to users and the protocol.

• Cases in which offchain softwares serves critical role like cross chain bridges. In those cases offchain scripts closely monitors the events from the contracts and perform operations accordingly.
  • Protocols may run emergency scripts, like a lending protocol can run an emergency pause script which pauses the protocol if funds greater than a threshold are pulled out from contracts.
  • Some protocols delegate the responsibility of creating and managing the UI to the community. In that case external UI developers might not be aware of minute intricacies of the contracts and simply rely upon contract state and events. Any incorrect event can cause loss of funds to users.
  • Also indexing protocols like The Graph heavily relies on contract events. These indexing projects are then consumed by multiple external agents (like governance dashboards).

There could be other cases as well and for all of them incorrect event/event data could pose a critical threat.

It is really hard to estimate the possible impact of incorrect events but simply considering them as Informational just because they do not pose an immediate risk would be underestimation of their impact.

[GalloDaSballo]

It is really hard to estimate the possible impact of incorrect events but simply considering them as Informational just because they do not pose an immediate risk would be underestimation of their impact.

We cannot reasonably be conscious of a vulnerability for a system that is not in-scope, if the finding is limited to information in the in-scope system we must asses it as such.

This doesn't mean that other systems could incur risks in integrating, for example Two Rights Might Make a Wrong

[KnownFactC4]

Per the Autumn 2023 C4 Supreme Court verdicts, the Supreme Court's verdict on this issue is:

A bug whose consequence is faulty emission of event(s) shall be graded in line with its broader-level impact: For events which are used for additional on-chain processes such as bridging, inclusion proofs etc., issue will be graded based on impacted functionality. Bugs that cause non-compliance with EIPs shall be graded based on EIP ruling guidelines Failure to demonstrate the broader level impacts above shall cap the severity to Low. For clarification, bugs leading to readability or accessibility of data, or issues of display in frontends, are capped to Low.

Link to verdict: https://docs.google.com/document/d/1Y2wJVt0d2URv8Pptmo7JqNd0DuPk_qF9EPJAj3iSQiE/edit#heading=h.s0m3mqigsq5s