Identifying use-after-free crashes has become easier

33 views
Skip to first unread message

Gabriele Svelto

unread,
Nov 21, 2022, 6:49:30 AM11/21/22
to stability, dev-platform, crash-reporting-wg, cma...@mozilla.com
[cross-posting to dev-platform and crash-reporting-wg]

TL;DR

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.

Longer version:

Hiya all,
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]

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
OpenPGP_signature
Reply all
Reply to author
Forward
0 new messages