-
Notifications
You must be signed in to change notification settings - Fork 156
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
fix(security): DoS in parser #1239
Merged
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
Oppen
requested review from
igaray,
fmoletta,
entropidelic,
juanbono,
pefontana and
Juan-M-V
as code owners
June 15, 2023 13:59
Malicious input can cause a denial of service by exponentiating a number to a huge power and taking the CPU for galactic amounts of time, as well as exponentially increasing memory usage. The added test can trigger it before this commit even in release mode. At the time of writing this it's still running after 50' and more than 2700MB. This was found by the fuzzer using the externally reachable parser, even though the test only attacks the culprit here. The cause of this issue is the following: - Recently we added support for scientific notation numbers in the `data` section of an input program; - `NumBigUint` only supports `modpow` when all arguments are `BigUint`; - `FeltBigInt` for primitive-type exponents tried to avoid creating a new `BigUint` as an attempt at optimization, so it used `pow`+`mod_floor` instead; - This combination with a huge exponent means an ever increasing number of allocations. The fix consists in building the `BigUint` and using `modpow` instead. This uses constant space because internally it uses the Montgomery exponentiation algorithm. With this the test finishes in 11ms on my machine.
Oppen
force-pushed
the
fix/dos_int_parsing
branch
from
June 15, 2023 14:01
fa69875
to
f5157b9
Compare
MegaRedHand
approved these changes
Jun 15, 2023
Benchmark Results for unmodified programs 🚀
|
Codecov Report
@@ Coverage Diff @@
## main #1239 +/- ##
==========================================
+ Coverage 97.61% 97.63% +0.01%
==========================================
Files 88 88
Lines 36112 36137 +25
==========================================
+ Hits 35251 35281 +30
+ Misses 861 856 -5
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
pefontana
approved these changes
Jun 15, 2023
kariy
pushed a commit
to dojoengine/cairo-rs
that referenced
this pull request
Jun 23, 2023
* fix(security): DoS in parser Malicious input can cause a denial of service by exponentiating a number to a huge power and taking the CPU for galactic amounts of time, as well as exponentially increasing memory usage. The added test can trigger it before this commit even in release mode. At the time of writing this it's still running after 50' and more than 2700MB. This was found by the fuzzer using the externally reachable parser, even though the test only attacks the culprit here. The cause of this issue is the following: - Recently we added support for scientific notation numbers in the `data` section of an input program; - `NumBigUint` only supports `modpow` when all arguments are `BigUint`; - `FeltBigInt` for primitive-type exponents tried to avoid creating a new `BigUint` as an attempt at optimization, so it used `pow`+`mod_floor` instead; - This combination with a huge exponent means an ever increasing number of allocations. The fix consists in building the `BigUint` and using `modpow` instead. This uses constant space because internally it uses the Montgomery exponentiation algorithm. With this the test finishes in 11ms on my machine. * Leftover `dbg!` * Remove clippy allow
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.
Malicious input can cause a denial of service by exponentiating a number
to a huge power and taking the CPU for galactic amounts of time, as well
as exponentially increasing memory usage.
The added test can trigger it before this commit even in release mode. I
aborted the run after 40 minutes and over 2GB of memory.
This was found by the fuzzer using the externally reachable parser, even
though the test only attacks the culprit here.
The cause of this issue is the following:
data
section of an input program;NumBigUint
only supportsmodpow
when all arguments areBigUint
;FeltBigInt
for primitive-type exponents tried to avoid creating anew
BigUint
as an attempt at optimization, so it usedpow
+mod_floor
instead;of allocations.
The fix consists in building the
BigUint
and usingmodpow
instead.This uses constant space because internally it uses the Montgomery
exponentiation algorithm. With this the test finishes in 11ms on my
machine.
Checklist