What Are Feasibility Limitations?
At Immunefi, we sometimes receive reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. If it’s obviously feasible, then it seems there are no questions about the severity or payout amount. But if the bug report is less feasible or not feasible at all, suddenly questions arise.
Some examples of feasibility limitations are the amount of capital required to exploit a bug, whether the exploit could be undone by reverting the chain to a previous state, and the risk an attacker must accept to attempt to exploit the bug. It’s not always clear how such feasibility limitations should be factored in when evaluating a bug report.
This is why we’re releasing feasibility limitation standards. It lays out a set of feasibility limitations that projects should or should not cite when downgrading a bug report’s impact, severity, or payout amount.
This document was developed in consultation with the whitehat community and numerous projects in the web3 space. It is being continually updated. The following standards are recommendations for projects and only a starting point for Immunefi’s own evaluation. They may be bent or broken to account for complexity on a case-by-case basis.
How Feasibility Limitations Affect A Bug Report’s Impact
The impact of a bug is calculated before, and separately from, feasibility limitations. Feasibility limitations only change how much a project pays for a bug report.
So, a bug with a massive impact that is infeasible would still have that impact and severity, though it would be rewarded differently based on that infeasibility.
For example, if a bug report demonstrates theft of funds of $1 billion but requires more capital than exists anywhere to execute the attack, then the impact is still $1 billion, despite its infeasibility. In this case, Immunefi’s policy is that it should be rewarded, though at a reduced amount.
The Standards
This list is continually being updated:
Attacks With A Financial Risk To The Attacker
When Is An Impactful Attack Downgraded To Griefing?
Attacks Involving Access to Privileged Addresses for Smart Contract Impacts
Attacks Involving Undeployed Code on GitHub or Equivalent for Smart Contract Impacts
Comments
0 comments
Article is closed for comments.