-
Notifications
You must be signed in to change notification settings - Fork 431
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
Restrict wildcard selectors to have exactly one other message #1708
Conversation
CI failures fixed in #1733 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally believe that we should favour this PR in contrast to #1706
The reason is that emerging contracts pattern like diamond proxy pattern may rely on wildcard selector. While we do solve the problem of upgradability with set_code_hash
by removing the selector we would harm the modularity of ink! smart contracts.
Restricting wildcard selector ensures that we close the vulnerability while maintaining the support for proxy patterns.
Codecov Report
@@ Coverage Diff @@
## master #1708 +/- ##
==========================================
+ Coverage 70.74% 70.90% +0.16%
==========================================
Files 207 206 -1
Lines 6617 6493 -124
==========================================
- Hits 4681 4604 -77
+ Misses 1936 1889 -47
... and 63 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Implementation of IIP-2 , one of the possible solutions to #1643.
This PR tightens the usage of wildcard selectors, requiring exactly one other message with a well-known reserved selector to be defined.
It is instructive to visualise the message dispatch as a
match
statement (indeed this is what is generated byink!
). Currently when no wildcard is used it looks like:This is an exhaustive match statement, so we can guarantee that the message will be handled by the target contract.
Wildcard selectors (aka fallback functions) are often used to bypass this built in static message dispatch, and forward/delegate messages to other contracts. So in the presence of a wildcard the match statement will become non-exhaustive:
It is easy to see here, that the contract will first try and match a local selector, before falling back to the wildcard selector. This is where the selector clashing vulnerability manifests, the proxy contract can intercept a message intended to be routed by the wildcard.
What this PR does, for the second example when using a wildcard selector, the match statement will always have only two branches:
By restricting the wildcard selector to having exactly one other message with a fixed selector, we have the guarantee that a message intended for the wildcard handler cannot be intercepted by another locally defined message.
todo