Fault in out-of-scope library, impact in in-scope contract, to reward or not to reward
Closed this issue · 3 comments
Hi,
Contract A is in scope and uses library B, which is not in scope.
Library B has a bug, and contract A can be proved to misbehave (i.e. provable HM-compatible impact) because of this bug.
Are such issues considered for rewarding?
I did not find any source of truth with regard to this situation, only comments here and there on submissions, and I just realized my assumptions - that come from Immunefi, where such issues are rewarded - on the subject may just be incorrect here.
TY!
A comment on twitter should not be looked at proof that the finding was actually awarded and paid out
By definition if Library B is used in Contract A, then the functions used are part of the scope
A function that is not used cannot be claimed into scope
The finding would be judged on the impact on Contract A, if B can impact it then I think it would be considered
I think it should be considered in scope only if it's a known library (like OZ) and the bug is known.
If it's just some library that the sponsor wrote and they've omitted it from scope then any bug found in the library should be OOS imo.
Otherwise, the sponsor can refactor most of the code to a library and reduce the official scope size without reducing the actual scope.
Also note that on Immunefi the scope has a different meaning than on C4. On C4 the bigger the scope is the bigger the pool of the contest (as there's more code to review). On Immunefi it just means that the sponsor is committed to paying a bounty if any bug is found - so in that case it makes sense to say that any bug that affects the contract should be considered in scope.
Per the Autumn 2023 C4 Supreme Court verdicts, the Supreme Court's verdict on this issue is:
We would like to clarify the situation where an in-scope contract composes/inherits with an OOS contract, and the root cause exists in the OOS contract. In such cases, the finding is to be treated as OOS, while exceptional scenarios are at the discretion of the judge.
At the consultative level, we advise that the sponsor (not the scout) must be held responsible for the final list of files in scope (scope.txt). This would remove any gray areas around scope when contracts are interdependent. The Sponsor must understand that adding a file to scope.txt means it’s in scope, while the omission of a file means it’s out of scope, even if the file will be part of the deployed contracts.
Link to verdict: https://docs.google.com/document/d/1Y2wJVt0d2URv8Pptmo7JqNd0DuPk_qF9EPJAj3iSQiE/edit#heading=h.3dpk76zh9wl5