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

gas: fix the computation of self.promises_gas #8179

Merged
merged 4 commits into from
Dec 8, 2022

Conversation

nagisa
Copy link
Collaborator

@nagisa nagisa commented Dec 7, 2022

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.


The fix in this PR has been included in 1.29.3 (72d4a4d) and 1.30.0-rc.6 (4290758).

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`.
@nagisa nagisa requested a review from a team as a code owner December 7, 2022 11:40
// 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);
Copy link
Collaborator

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

@jakmeier jakmeier 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 we should merge this as-is to reach parity with the rc versions. Follow-up fixes can be discussed in separate issues.

@near-bulldozer near-bulldozer bot merged commit c5610cd into master Dec 8, 2022
@near-bulldozer near-bulldozer bot deleted the nagisa/gas-logic-fix branch December 8, 2022 16:27
@akhi3030
Copy link
Collaborator

akhi3030 commented Dec 9, 2022

I think we should merge this as-is to reach parity with the rc versions. Follow-up fixes can be discussed in separate issues.

@jakmeier, @nagisa: what are the follow-up issues? Did we create github issues for them?

@nagisa
Copy link
Collaborator Author

nagisa commented Dec 9, 2022

#5148

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