[dev-platform] Identifying use-after-free crashes has become easier

[Gabriele Svelto]

[cross-posting to dev-platform and crash-reporting-wg]

TL;DR



Longer version:

 Hiya all,






Special thanks to Chris Martin for tackling this important issue!

 Gabriele

[1] Report crashes at amd64 non-canonical addresses correctly
    https://bugzilla.mozilla.org/show_bug.cgi?id=1493342
[2] https://wiki.mozilla.org/Crash_reporting_improvements#Rationale_3

--
You received this message because you are subscribed to the Google Groups 
"dev-platform@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dev-platform+unsubscr...@mozilla.org.
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/299133b6-0f75-35f8-9d6b-f90f1ed59bf7%40mozilla.com.

Use-after-free crashes in x86-64 builds now have their real crashing address shown in Socorro instead of a platform-specific placesholder. That's the `e5e5e5e5e5e5e5e5` pattern, if you see it - or a portion of it - in a crash report it means trouble. File a bug and mark it as security-sensitive. for a long time we haven't been able to correctly report the crash address of crashes that hit non-canonical addresses on x86-64. This is because of a fundamental design flaw of the x86-64 exception behavior that would not return the address in these cases (it would raise a general protection fault), leaving to the application the job of figuring out what happened. The poison pattern used by our memory allocator fell among the non-canonical addresses and thus use-after-free crashes would often appear having accessed the NULL pointer or 0xffffffffffffffff depending on the platform. Fortunately our new Rust-infused stack walker has been augmented with a disassembler so it can retrieve the actual crashing address by inspecting the instruction that caused the crash. In the short term this makes identifying UAF and wild pointer crashes easier, as the crashing address is not useless anymore. On the long run it will allow us to run more analyses to weed out bad memory, corrupted executables, unaligned accesses and more. Bug 1493342 [1] contains even more nitty gritty details if you're interested. You can also find a list of the things we'll be able to do with this functionality on the wiki [2]

OpenPGP_signature
Description: OpenPGP digital signature