gas: fix the computation of self.promises_gas
#8179
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With the wrapping computation of `new_used_gas` any contract is in full control of this value, including those that are actually less than either operand (due to overflows.) This is not actually a big deal by itself, if not for the fact that it gives an opportunity for the attacker to nuke the entire network out of service. The in-line comments largely explain the reasoning behind the fix and why it preserves the protocol-facing behaviour, thus not necessitating a protocol version change. To reiterate what the comments say, basically the only case that we want to resolve is for when the attacker picks a value of `new_used_gas` such that it is less than `burnt_gas`. Instead of asserting and aborting we simply set `self.promises_gas = 0`.
Ekleog-NEAR
reviewed
Dec 7, 2022
| // replacing the wrapping subtraction with a saturating one we make sure that the | ||
| // resulting value of `self.promises_gas` is well behaved (becomes 0.) All a potential | ||
| // attacker has achieved in this case is throwing some of their gas away. | ||
| self.promises_gas = used_gas_limit.saturating_sub(self.fast_counter.burnt_gas); |
There was a problem hiding this comment.
Given this is for the next release, do we want to take advantage of it to also fix the TODO just two lines above this diff, and just set self.promises_gas to 0 in the new protocol version? I’m thinking it’d allow simplifying quite a lot the comments, as the failure mode would become obvious.
There was a problem hiding this comment.
I don’t feel like this PR is the right place for the more involved changes to this code. Any further fixes for this issue should be part of fixing the referenced issue (#5148) proper, and I don’t believe we have resources available to (re-)assign somebody to this immediately.
jakmeier
approved these changes
Dec 7, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the wrapping computation of
new_used_gasany contract is in fullcontrol of this value, including those that are actually less than
either operand (due to overflows.)
This is not actually a big deal by itself, if not for the fact that it
gives an opportunity for the attacker to nuke the entire network out of
service.
The in-line comments largely explain the reasoning behind the fix and
why it preserves the protocol-facing behaviour, thus not necessitating a
protocol version change. To reiterate what the comments say, basically
the only case that we want to resolve is for when the attacker picks
a value of
new_used_gassuch that it is less thanburnt_gas. Insteadof asserting and aborting we simply set
self.promises_gas = 0.The fix in this PR has been included in 1.29.3 (72d4a4d) and 1.30.0-rc.6 (4290758).