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

Simplify UUPSUpgradeable along the lines of ERC1822 #3021

Merged
merged 24 commits into from
Jan 13, 2022

Conversation

Amxx
Copy link
Collaborator

@Amxx Amxx commented Dec 13, 2021

Reviewing our initial design decisions for UUPSUpgradeable and replacing the rollback test with a simpler security mechanism with less attack surface.

PR Checklist

  • Tests
  • Documentation
  • Changelog entry

@Amxx Amxx mentioned this pull request Dec 14, 2021
Copy link

@RafaBlockDev RafaBlockDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Viewed! 🧐

RafaBlockDev
RafaBlockDev previously approved these changes Dec 28, 2021
Copy link

@RafaBlockDev RafaBlockDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved 🌎

Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR is mostly just pending documentation and some comments in the code.

contracts/mocks/UUPS/legacy/UUPSLegacyV1.sol Outdated Show resolved Hide resolved
contracts/mocks/UUPS/legacy/UUPSLegacyV1.sol Outdated Show resolved Hide resolved
contracts/mocks/UUPS/legacy/UUPSLegacyV1.sol Outdated Show resolved Hide resolved
contracts/proxy/ERC1822/IProxiable.sol Outdated Show resolved Hide resolved
test/proxy/utils/UUPSUpgradeable.test.js Outdated Show resolved Hide resolved
test/proxy/utils/UUPSUpgradeable.test.js Outdated Show resolved Hide resolved
contracts/proxy/utils/UUPSUpgradeable.sol Outdated Show resolved Hide resolved
test/proxy/utils/UUPSUpgradeable.test.js Outdated Show resolved Hide resolved
test/proxy/utils/UUPSUpgradeable.test.js Outdated Show resolved Hide resolved
contracts/proxy/ERC1967/ERC1967Upgrade.sol Show resolved Hide resolved
@frangio frangio changed the title ERC1822 implementation of UUPSUpgradeable Simplify UUPSUpgradeable along the lines of ERC1822 Jan 13, 2022
@frangio frangio dismissed a stale review via efe04e3 January 13, 2022 18:37
@frangio frangio merged commit e192fac into OpenZeppelin:master Jan 13, 2022
@Amxx Amxx deleted the feature/upgradeToSecure-uuid branch January 14, 2022 17:34
@JuliusBrain
Copy link

You mentioned "replacing the rollback test with a simpler security mechanism with less attack surface." but can you explain what attack vectors were possible on the old mechanism? I don't see it being discussed anywhere and it's been some time since merge happed of this branch.

Or can you lead me to some discussion on your forum or some docs that explains that in more details? Quite frankly, the explanation wasn't sufficient enough and didn't help me to decide which version should I use.

I will stick with the old way as it seems more robust against potentially leaving out the upgrade functionality in the implementation and I don't see such protection in the new version.

@frangio
Copy link
Contributor

frangio commented Apr 4, 2022

@JuliusBrain Sorry for the lack of clarity.

One of our past security advisories concerned UUPS upgradeability (GHSA-5vp3-v4hc-gx76). The rollback mechanism was not exactly the cause, because there was a simpler way to execute the attack, but had that simpler way not been available this mechanism would've also been an attack vector leading to the same issue.

That said, by "attack surface" we do not mean concrete attack vectors. What we're referring to is the fact that complexity increases the number of things that can go wrong and eventually may become attack vectors. In this case, we came to the conclusion that this complexity was not providing enough benefit to justify the increased surface. While the idea of doing a rollback test was very attractive to us, it is not 100% effective to prevent the removal of upgradeability, which means it does not prevent a malicious actor from doing it. What remains is protection from this happening by accident, and we believe the new mechanism is good enough to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants