TOB-FUEL-31: Sway parser is crashing on certain inputs

[xgreenx]

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

#[test_fuzz::test_fuzz]
pub fn fuzz_parse(buf: &[u8]) {
    if let Ok(str) = String::from_utf8(Vec::from(buf)) {
        let type_engine = TypeEngine::default();
        let decl_engine = DeclEngine::default();
        let query_engine = QueryEngine::default();
        let engines = Engines::new(&type_engine, &decl_engine, &query_engine);
        let _result = parse(Arc::from(str), engines, None);
    }
}

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

script;
fn main() {
    let a: b256 =
0x000000([[[[[[[[[[[[[[[[[[[[[[[[[[[[[000000000000000000000009000(([[[[[[[[[[[[[[[[[
[[[[[[[[[[[[[[
-----
script;
fn main() {
    let a: b256 =
0x000000000000000000000000000000000(([[[[[[[[[[[[[[[[[[[[[[[[[[[[[[{{{{{{is_empty({{
{{{{{{{{{{{{{{
-----
script;
fn main() {
    let a: b256 =
0x0000000000000[[[[[[[[[[[[[[[00000(([[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[y;[[00000(([[[[[
[[[[[[[[[[[[[
-----
script;
fn main() {
    let a: b256 =  00000000@(((((((((((((((((C(((((((((((((((((
((((((alle(((((C(((((((((((((t {
  d, wriet {
#n -----
script;
fn main() {
    let a: b256 =
0x00000E000000(((((((((((((((((((((((((((((((000000000000000000000(((((((((((((((((C
((((((((((((((
-----
script;
fn main() {
(([[[[[[[[[[[[[[[[[[@[[[[[[000000000p000000000000000(([[[[[[[[[[[[[[[[[[[[[[[[[yable
, storage(readG write)]
qn -----
script;
fn main() {
  b256 =
0x00000E000000000000000000000000000(((((((((((((((((C((((((((((((((((((((((((allet
((((((((((((((((((((((((
-----
script;
fn main() {
    let a: b256 =
0x000000000000000000000000000000000(([[[[[[[[[[[r[[[[[[[[[[[[[[[[[[[y[[[[[[[[[[[[[[[
[[[[[[[[[[[[[[

Unwrap on None value

The parser panics in emit_error in line 50.

Figure 31.3: Input that causes a panic.

script;

fn main(256߄

Panic while slicing

The parser panics when calling as_str.

Figure 31.4: Input that causes a panic.

script;
fn karr() {
    let c: f828 =  0x00000000000000000000000vncifxp;
abi Zezybt {
    #[mfzbezc, storage(r#
true }
}
cug

Panic while creating span

The parser panics when calling span.

Figure 31.4: Hex encoded inputs separated by ----- that cause a panic.

7363726970743b0a0a636f7265666e206d61696e2829207b0a202020206c657420613a2062323536203d
202030783030303e30303030303030736372692073203d2022666c696272617279204932343b0a0a7573
6520636f72653a3a7072696d6974697665733a3a2a3b0a757365207374643a3a6173736572743a3a6173
736572743b0a0a2f2f2fdfab
-----
6c6962726172793b0a0a757365203a3a646174615f737472756374757265613a3a7b536f6d65456e756d
2c20536f6d655374727563747d3b0a75736520636f72653a3a6f70733a3a45713b0a0a696d706c204571
28666f7220536f6d65456e756d3c7533323e207b2f2f20414e43484f523a206c69627a6172790a2f2a20
414e43484f523a206d6f64756c650a6c6962726172793b0a2f2f20414e43594f525f454e443a206d6f64
0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a756c650a0a2f2f2043616e6e6f74df96

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.

[andresmayorca]

I'm interested in this issue

[IGI-111]

The parser still contains the stack overflow panics, but fixing those is going to require a significant rewrite.

[xgreenx]

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.