br_table size is out of bounds

[zdiff]

I have a yara rule file with 131,517 strings and when using the yr compile command, it is crashing with the following error:

RUST_BACKTRACE=full yr compile --output rule.yarc rule.yar

thread 'main' panicked at lib/src/compiler/mod.rs:695:10:
WASM module is not valid: WebAssembly translation error

Caused by:
    Invalid input WebAssembly code at offset 271360: br_table size is out of bounds

Stack backtrace:
   0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
   1: core::ops::function::FnOnce::call_once{{vtable.shim}}
   2: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
   3: rayon::iter::plumbing::bridge_producer_consumer::helper
   4: rayon_core::join::join_context::{{closure}}
   5: rayon_core::registry::in_worker
   6: rayon::iter::plumbing::bridge_producer_consumer::helper
   7: rayon_core::join::join_context::{{closure}}
   8: rayon_core::registry::in_worker
   9: rayon::iter::plumbing::bridge_producer_consumer::helper
  10: rayon_core::join::join_context::{{closure}}
  11: rayon_core::registry::in_worker
  12: rayon::iter::plumbing::bridge_producer_consumer::helper
  13: rayon_core::join::join_context::{{closure}}
  14: rayon_core::registry::in_worker
  15: rayon::iter::plumbing::bridge_producer_consumer::helper
  16: rayon_core::join::join_context::{{closure}}
  17: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
  18: rayon_core::registry::WorkerThread::wait_until_cold
  19: rayon_core::registry::ThreadBuilder::run
  20: std::sys::backtrace::__rust_begin_short_backtrace
  21: core::ops::function::FnOnce::call_once{{vtable.shim}}
  22: std::sys::pal::unix::thread::Thread::new::thread_start
  23: start_thread
             at ./nptl/pthread_create.c:442:8
  24: __GI___clone3
             at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
stack backtrace:
   0:     0x564e7164fd95 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h1b9dad2a88e955ff
   1:     0x564e716792db - core::fmt::write::h4b5a1270214bc4a7
   2:     0x564e7164d40f - std::io::Write::write_fmt::hd04af345a50c312d
   3:     0x564e71651411 - std::panicking::default_hook::{{closure}}::h96ab15e9936be7ed
   4:     0x564e716510ec - std::panicking::default_hook::h3cacb9c27561ad33
   5:     0x564e70bb188e - yr::main::{{closure}}::heb4a2c6a70fffb9f
   6:     0x564e71651caf - std::panicking::rust_panic_with_hook::hfe205f6954b2c97b
   7:     0x564e716518d7 - std::panicking::begin_panic_handler::{{closure}}::h6cb44b3a50f28c44
   8:     0x564e71650259 - std::sys::backtrace::__rust_end_short_backtrace::hf1c1f2a92799bb0e
   9:     0x564e71651564 - rust_begin_unwind
  10:     0x564e70b23553 - core::panicking::panic_fmt::h3d8fc78294164da7
  11:     0x564e70b23a26 - core::result::unwrap_failed::hfa79a499befff387
  12:     0x564e70ec3ba4 - yara_x::compiler::Compiler::build::h87040e3e9d74f796
  13:     0x564e70bc137a - yr::commands::compile_rules::hb614a5faf462acc8
  14:     0x564e70badba4 - yr::commands::compile::exec_compile::hf8b13c7379073c56
  15:     0x564e70bb0d80 - yr::main::h6dd8825c4f911447
  16:     0x564e70bc63b3 - std::sys::backtrace::__rust_begin_short_backtrace::h68179dc5cb28cf2f
  17:     0x564e70bc630d - std::rt::lang_start::{{closure}}::hcdcc5b54aa3d2cb3
  18:     0x564e71643e00 - std::rt::lang_start_internal::h5e7c81cecd7f0954
  19:     0x564e70bb18c5 - main
  20:     0x7f966f2bed90 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  21:     0x7f966f2bee40 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:392:3
  22:     0x564e70b23da5 - _start
  23:                0x0 - <unknown>

I am building yr using the main branch on the latest commit (e7f6363)

I understand that this is a ridiculous amount of strings to have in a single rule, but in yara 4, I was able to set --max-strings-per-rule and compile the file successfully.

[plusvic]

What's the condition in the rule?

[zdiff]

What's the condition in the rule?

any of them

I was able to recreate this bug using a (poorly written) python script:

#!/usr/bin/env python
import random
import string


def main():
    file_content = ['rule big_rule : big_rule {\n', '  strings:\n']
    for count in range(131533):
        file_content.append(f'    ${count} = "{''.join(random.sample(string.ascii_letters, 16))}" wide ascii nocase fullword\n')   
    file_content.extend(['  condition:\n', '    any of them\n', '}'])
    with open('big_rule.yar', 'w') as rule_handle:
        rule_handle.writelines(file_content)

if __name__=="__main__":
    main()

[plusvic]

I'm afraid there's little I can do about this, except limiting the number of patterns per rule to a reasonable number in order to prevent the crash. YARA and YARA-X have different constraints, and their own set of advantages and disadvantages. This is an extreme edge case that hits a limit that is hard or impossible to circumvent.