Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NestedFactory.addOperator/removeOperator have no effect until importOperators #62

Closed
code423n4 opened this issue Feb 12, 2022 · 1 comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate This issue or pull request already exists

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/FeeSplitter.sol#L155

Vulnerability details

Impact

addOperator/removeOperator being run alone don't have any effect, as the cache is used in operations, which is only updated when an implementation is added or removed via importOperators.

If an operation is added via addOperator, but importOperators isn't yet called, the cache doesn't include new operation and it's not usable.

More dangerously, when operator is removed with removeOperator, it is still can be used, even if rebuildCaches was called after that, as an operator is removed from cache only when implementation is zero, so until that is done via importOperators, the deleted operator can be still called by user facing functions.

If operator removal was linked to security considerations this opens up an attack surface, when a malicious user front runs importOperators, invoking the operator to be deleted as it’s still in the cache and can be accessed with callOperator.

This dependency was described among other points in code-423n4/2021-11-nested-findings#139, but isn't yet addressed, as the need of atomic run and now corrected removeOperator implementation were independent issues.

Proof of Concept

NestedFactory.addOperator/removeOperator only manage the operators array:

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/NestedFactory.sol#L100-122

rebuildCaches remove operator from cache only after its implementation is set to zero:

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/OperatorResolver.sol#L74

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/abstracts/MixinOperatorResolver.sol#L36-45

importOperators is effectively adds and removes operators by changing their implementation:

https://github.com/code-423n4/2022-02-nested/blob/main/contracts/OperatorResolver.sol#L52-70

This way addOperator/removeOperator should only be run atomically with importOperators within one transaction to prevent front running.

Recommended Mitigation Steps

As both addOperator/removeOperator aren't effective alone, while addOperator/removeOperator and importOperators are both only owner run, and, given that this functions are basically two parts of one operation, consider add importOperators call to addOperator/removeOperator.

addOperator/removeOperator arguments to be expanded to include Operator structure to be set for the operator via importOperators.

@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Feb 12, 2022
code423n4 added a commit that referenced this issue Feb 12, 2022
@maximebrugel maximebrugel added the duplicate This issue or pull request already exists label Feb 14, 2022
@maximebrugel
Copy link
Collaborator

Duplicated : #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants