Open xgreenx opened 1 year ago
I'm interested in this issue
The parser still contains the stack overflow panics, but fixing those is going to require a significant rewrite.
We marked the issue as acknowledged. We plan to fix it in the future, but as stated above, it requires rewriting of the parser. It is not a critical issue and doesn't bring vulnerabilities into users' code.
We keep this issue open to track the progress in our backlog.
Description
A fuzzing campaign for the sway parser revealed several crashes. This finding serves as an umbrella finding to list all the different crashes we observed. The harness for the fuzzer is shown in the following figure.
Figure 31.1: Fuzz harness
The findings are relevant for use cases where untrusted Sway programs are parsed, for example as part of a Sway playground application, similar to the Rust playground.
Stack overflow
The Rust program invoking the parser with the following inputs might panic with the message thread 'fuzz_parse_fuzz::entry' has overflowed its stack.
Figure 31.2: Inputs separated by ----- that cause a stack overflow
Unwrap on None value
The parser panics in emit_error in line 50.
Figure 31.3: Input that causes a panic.
Panic while slicing
The parser panics when calling as_str.
Figure 31.4: Input that causes a panic.
Panic while creating span
The parser panics when calling span.
Figure 31.4: Hex encoded inputs separated by ----- that cause a panic.
Recommendations
Short term, avoid panicking by handling the errors appropriately. For the stack overflows, make sure to avoid recursive calls and instead implement parsing iteratively. Long term, deploy a fuzzer for the Sway parser. The above fuzz harness can be used together with Trail of Bits’ test-fuzz fuzzer. The instructions for setting it up can be found in the documentation of the project.