Attacks Involving Access to Privileged Addresses for Smart Contract Impacts
This document is intended to provide guidance regarding the evaluation of bug report submissions involving privileged addresses for smart contract impacts. However, this should only be used in the event of a lack of information clarifying which addresses are considered to be privileged addresses in the respective bug bounty program. If such information or section exists, then all those and only those in the list are to be considered privileged addresses per the terms of that bug bounty program.
Privileged Address
A privileged address is defined as an address within the ecosystem of the respective project of the bug bounty program with abilities that exceed that of what a user can acquire within the said ecosystem of the project. The term “privilege” is, within the scope of this rule, thus defined as one or more of these abilities.
Out of Scope - Attack Vector
Bug bounty programs on Immunefi have the standard wording of “Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed” under the section labeled “Out of Scope & Rules”. However, this does not mean that if a privileged address is impacted by the exploitation of a vulnerability that the bug report is out of scope. Rather, it means that if an attack vector exploiting a vulnerability requires the use of a privileged address, it would be out of scope.
Exceptions
An exception to validity may be made in the case of an error in the privileges granted to the respective address or addresses whereby the said address does not originally have privileges that can cause an impact listed in the Impacts in Scope section but an exploit in a code vulnerability grants the additional privileges required to cause the impact. However, this may result in the downgrade of your bug report by one severity level.
For example, if an address listed as privileged holds tokens that are under a vesting schedule, but a vulnerability allows for canceling the vesting schedule and thus unlocking all the tokens, considered as an impact of theft of funds given that the funds are acquired against the terms of agreement, then it would not immediately be considered as out of scope but may be downgraded by one severity level.
Another exception may apply whereby impacts listed on the Impacts in Scope table can occur due to a logic error exploitable by a privileged address. Logic errors are considered valid bug reports.
For example, if more funds can be withdrawn from the treasury than the privileged address enters as the withdrawal amount.
Unique Circumstances
Immunefi is constantly gathering information with regards to unique circumstances and edge cases as well as incorporating this knowledge into objective bug bounty programs that minimize uncertainty for both projects and security researchers. However, if there is a situation whereby the project’s bug bounty program nor this document covers a unique issue, please call on mediation if a mutually agreed decision cannot be made. The Immunefi mediation team will evaluate the report on a case-by-case basis. These reports may be considered as in-scope, in-scope but with a downgrade, or out-of-scope.
This includes cases of areas with uncertainty whereby there is no modification to the privileges provided, but it can be interpreted that the address was not intended to have such privileges.
For example, it can be interpreted that it was unintended to have a recipient of a governance mandate with payment from governance tied to a vesting schedule to accelerate the vesting schedule themselves at their will. As these intentions are usually expressed off-chain, it is necessary for a more holistic look into the report on a case-by-case basis and thus cannot have every instance covered in this article. This also includes cases whereby the role itself is acquired outside the parameters of intention.
Comments
0 comments
Article is closed for comments.