Abrt in google_breakpad::PrintStackMachineReadable |
||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6275281757929472 Fuzzer: libFuzzer_minidump_fuzzer Job Type: libfuzzer_chrome_asan_debug Platform Id: linux Crash Type: Abrt Crash Address: 0x03e900005d72 Crash State: google_breakpad::PrintStackMachineReadable google_breakpad::PrintProcessStateMachineReadable PrintMinidumpProcess Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=510445:510468 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6275281757929472 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Jan 29 2018
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Jan 29 2018
mark@ this seems more or less inevitable to me when fuzzing. Is an attacker being able to crash Breakpad (or would it be the entire browser?) by causing a malformed minidump to be processed something we should mitigate against at the minidump processing level?
,
Jan 30 2018
Yes, absolutely.
,
Jan 30 2018
To be clear, the thing that we’re concerned about here is a malformed minidump trashing server-side processing. This report (and other things involving malformed minidumps) don’t really have much or any client-side impact.
,
Jan 30 2018
So would the right move here be to replace the asserts with early exits?
,
Jan 30 2018
Oh, wait, this is an assert? That’s basically OK. I thought that this was an “organic” crash.
,
Jan 30 2018
(from a security impact perspective, at least.)
,
Jan 30 2018
Aha. That’s trivially easy to hit. It doesn’t take much to construct a minidump that results in an empty code_file. Since it’s actually happening right in the “print” function, it doesn’t actually affect production use. In production, the processor library cranks out the stackwalk, but doesn’t do any printing. While I don’t have any problems leaving the assert in place particularly in this case, we could also drop the assert and just allow the empty string to pass.
,
Dec 1
ClusterFuzz testcase 6275281757929472 appears to be flaky, updating reproducibility label.
,
Dec 1
ClusterFuzz testcase 6275281757929472 is flaky and no longer crashes, so closing issue. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ClusterFuzz
, Jan 29 2018Owner: lgrey@chromium.org
Status: Assigned (was: Untriaged)