Segfault when parsing malformed minidump file

[5225225]

use symbolic::common::ByteView;
use symbolic::minidump::processor::ProcessState;

fn main() {
    let data = b"MDMP\x93\xa7\x00\x00\r\x00\x00\x00 \xff\xff\xff\xff\xff\xff\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
    let bv = ByteView::from_slice(data);
    ProcessState::from_minidump(&bv, None);
}

Without being run with any sanitizers, this segfaults.

With RUSTFLAGS="-Zsanitizer=address" cargo run -Zbuild-std --target x86_64-unknown-linux-gnu, we get

=================================================================
==436795==ERROR: AddressSanitizer: negative-size-param: (size=-4294967040)
    #0 0x55af9df89025 in __interceptor_memcpy /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:827:5
    #1 0x7fab5dee4ab0 in std::char_traits<char>::copy(char*, char const*, unsigned long) /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:409:49
    #2 0x7fab5dee4ab0 in std::basic_streambuf<char, std::char_traits<char> >::xsgetn(char*, long) /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/streambuf.tcc:56:25
    #3 0x7fab5debb222 in std::basic_streambuf<char, std::char_traits<char> >::sgetn(char*, long) /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/streambuf:363:28
    #4 0x7fab5debb222 in std::istream::read(char*, long) /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/istream.tcc:694:40
    #5 0x55af9e05d22b in google_breakpad::Minidump::ReadBytes(void*, unsigned long) /home/jess/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-minidump-8.5.0/third_party/breakpad/src/processor/minidump.cc:5567:16
    #6 0x55af9e05cc10 in google_breakpad::Minidump::Read() /home/jess/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-minidump-8.5.0/third_party/breakpad/src/processor/minidump.cc:5272:19
    #7 0x55af9e034382 in process_minidump /home/jess/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-minidump-8.5.0/cpp/processor.cpp:38:23
    #8 0x55af9e02026e in symbolic_minidump::processor::ProcessState::from_minidump::h7d19cc4f420158d2 /home/jess/.cargo/registry/src/github.com-1ecc6299db9ec823/symbolic-minidump-8.5.0/src/processor.rs:1081:13
    #9 0x55af9e003cc6 in scratch5I5Fni4DI::main::hfa28c932c255ccf1 /tmp/scratch5I5Fni4DI/src/main.rs:7:5
    #10 0x55af9e00432a in core::ops::function::FnOnce::call_once::hba29790aceba71c6 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
    #11 0x55af9e004634 in std::sys_common::backtrace::__rust_begin_short_backtrace::h3bd0f99741317a17 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:123:18
    #12 0x55af9e004983 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h0d4ab6f1afee4ecc /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:145:18
    #13 0x55af9f71bead in core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::he5b45d96cadee5ed /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:259:13
    #14 0x55af9f7436be in std::panicking::try::do_call::h6cc1035b2e093ebe /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:406:40
    #15 0x55af9f74c84a in __rust_try std.7a5eabd0-cgu.6
    #16 0x55af9f741ce2 in std::panicking::try::h37f656e25d062c2c /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:370:19
    #17 0x55af9f75c869 in std::panic::catch_unwind::h57e10e9d10f229f3 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:133:14
    #18 0x55af9f7bd39b in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::h8bc6b9291003eaf3 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:128:48
    #19 0x55af9f7438cd in std::panicking::try::do_call::ha0cd72e075493063 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:406:40
    #20 0x55af9f74c84a in __rust_try std.7a5eabd0-cgu.6
    #21 0x55af9f74271b in std::panicking::try::hb3e5f707d205874a /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:370:19
    #22 0x55af9f75cb59 in std::panic::catch_unwind::hdf51ffa5baa23030 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:133:14
    #23 0x55af9f7bcbf9 in std::rt::lang_start_internal::h0a05032b34861450 /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:128:20
    #24 0x55af9e0048e5 in std::rt::lang_start::hab2902a4e10f59bd /home/jess/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:144:17
    #25 0x55af9e003fbb in main (/home/jess/.cache/cargo/target/x86_64-unknown-linux-gnu/debug/scratch5I5Fni4DI+0x497fbb)
    #26 0x7fab5da62b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
    #27 0x55af9df749ad in _start (/home/jess/.cache/cargo/target/x86_64-unknown-linux-gnu/debug/scratch5I5Fni4DI+0x4089ad)

Address 0x55b09fa59e60 is a wild pointer inside of access range of size 0x000000000001.
SUMMARY: AddressSanitizer: negative-size-param /rustc/llvm/src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:827:5 in __interceptor_memcpy
==436795==ABORTING

Not sure if this is a security vulnerability or not. Could be, but I've not looked at the format + code to see how to exploit this. This looks to be entirely minidump's problem.

[Swatinem]

This seems to be deep in breakpad C++ code. Given that @jan-auer has started replacing that with rust-minidump it might not be worth fixing this in the breakpad processor, and rather wait for that refactor to land.

@jan-auer @Gankra Might be good to check how the above testcase behaves with rust-minidump, and make sure there are regression tests for it both upstream and here.

[Swatinem]

While the underlying code still exhibits this segfault, it is now being hidden behind a feature flag (probably to be completely removed in the next major release).

We are also not running any of this code in production anymore, and haven’t noticed any subprocess restart (aka crash) since that change! 🎉