Crash in [@ libsystem_platform.dylib@0x817]
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | disabled |
firefox75 | --- | unaffected |
firefox76 | --- | unaffected |
firefox77 | --- | disabled |
firefox78 | --- | disabled |
firefox79 | --- | verified |
People
(Reporter: bmaris, Assigned: kershaw)
References
(Regression)
Details
(Keywords: crash, regression, sec-high, Whiteboard: [sec-survey][post-critsmash-triage])
Crash Data
Attachments
(1 file)
47 bytes,
text/x-phabricator-request
|
dveditz
:
sec-approval+
|
Details | Review |
This bug is for crash report bp-5d6c647e-351c-435e-b7b5-6ec160200423.
Top 10 frames of crashing thread:
0 libsystem_platform.dylib libsystem_platform.dylib@0x817
1 XUL <name omitted> modules/libpref/Preferences.cpp:1538
2 XUL nsresult mozilla::Internals::GetPrefValue<bool*> modules/libpref/Preferences.cpp:4355
3 XUL mozilla::Preferences::GetBool modules/libpref/Preferences.cpp:4716
4 XUL mozilla::ipc::GeckoChildProcessHost::FillMacSandboxInfo ipc/glue/GeckoChildProcessHost.cpp:1679
5 XUL mozilla::net::SocketProcessHost::FillMacSandboxInfo netwerk/ipc/SocketProcessHost.cpp:299
6 XUL mozilla::ipc::GeckoChildProcessHost::AppendMacSandboxParams ipc/glue/GeckoChildProcessHost.cpp:1669
7 XUL mozilla::ipc::GeckoChildProcessHost::AsyncLaunch ipc/glue/GeckoChildProcessHost.cpp:635
8 XUL mozilla::ipc::GeckoChildProcessHost::LaunchAndWaitForProcessHandle ipc/glue/GeckoChildProcessHost.cpp:757
9 XUL mozilla::net::SocketProcessHost::Launch netwerk/ipc/SocketProcessHost.cpp:138
Affected versions
- macOS 10.15.5
- macOS 10.14.6
Affected platforms
- Nightly 77.0a1
Steps to reproduce
- Start firefox with -migration parameter
- Select to import from another browser
- Click Continue
Expected result
- Firefox successfully imported data from another browser
Actual result
- Firefox crashes when hitting continue
Regression range
- Since Firefox 76 is not affected by this I think this is a regression on Fx77, I'll try and find a range here but I can't use mozregression so I would have to do it manually.
Reporter | ||
Comment 1•4 years ago
|
||
I managed to find the regressor for this issue:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4babe5335da0a5600ae284c38996a5d67b703ffb&tochange=92eda1c0523df06ebd7c47ebff9730aa09f5079e
Bug 1625151 - [socket process] Move DNS resolution to socket process
Reporter | ||
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
On a debug build I'm seeing us fail this assertion: https://searchfox.org/mozilla-central/rev/b8fbb6ead517720daf0b0211115f407b4b951c74/toolkit/xre/nsXREDirProvider.cpp#912
This ties in with the crash, for some reason we're accessing prefs before they've been initialized.
Assignee | ||
Comment 3•4 years ago
|
||
Mark this as sec-high, since this is a UAF bug.
Here is what I found:
- We tried to launch socket process since a pref is changed.
- The pref name is released in Preferences::EnsureSnapshot.
- We tried to access the pref name at here.
I am not sure how to fix this properly. It seems that we should not launch socket process in the callback which observes the pref change.
:kmag, what do you think?
Assignee | ||
Comment 4•4 years ago
|
||
(In reply to Dave Townsend [:mossop] (he/him) from comment #2)
On a debug build I'm seeing us fail this assertion: https://searchfox.org/mozilla-central/rev/b8fbb6ead517720daf0b0211115f407b4b951c74/toolkit/xre/nsXREDirProvider.cpp#912
This ties in with the crash, for some reason we're accessing prefs before they've been initialized.
FWIW, I've also seen this assertion, but the root cause is different than this bug.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 6•4 years ago
|
||
Here is the details about this crash.
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x00007fff6ef68817 libsystem_platform.dylib`_platform_strcmp + 23
frame #1: 0x0000000107676d69 XUL`pref_Lookup(char const*, bool) + 425
frame #2: 0x00000001076cca85 XUL`nsresult mozilla::Internals::GetPrefValue<bool*>(char const*, bool*&&, mozilla::PrefValueKind) + 85
frame #3: 0x00000001076b674b XUL`mozilla::Preferences::GetBool(char const*, bool, mozilla::PrefValueKind) + 43
frame #4: 0x0000000107d4ea85 XUL`mozilla::ipc::GeckoChildProcessHost::FillMacSandboxInfo(_MacSandboxInfo&) + 53
frame #5: 0x0000000107c8956e XUL`mozilla::net::SocketProcessHost::FillMacSandboxInfo(_MacSandboxInfo&) + 14
frame #6: 0x0000000107d4ea01 XUL`mozilla::ipc::GeckoChildProcessHost::AppendMacSandboxParams(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >&) + 113
frame #7: 0x0000000107d4b035 XUL`mozilla::ipc::GeckoChildProcessHost::AsyncLaunch(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >) + 69
frame #8: 0x0000000107d4bd7f XUL`mozilla::ipc::GeckoChildProcessHost::LaunchAndWaitForProcessHandle(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >) + 79
frame #9: 0x0000000107c88c12 XUL`mozilla::net::SocketProcessHost::Launch() + 946
frame #10: 0x0000000107756584 XUL`mozilla::net::nsIOService::LaunchSocketProcess() + 276
frame #11: 0x0000000107756abf XUL`mozilla::net::nsIOService::NotifySocketProcessPrefsChanged(char const*) + 911
frame #12: 0x0000000107ac03ca XUL`mozilla::net::nsHttpHandler::PrefsChanged(char const*) + 106
frame #13: 0x000000010769236a XUL`NotifyCallbacks(char const*, PrefWrapper const*) + 186
frame #14: 0x00000001076b6c62 XUL`pref_SetPref(char const*, mozilla::PrefType, mozilla::PrefValueKind, PrefValue, bool, bool, bool) + 1026
frame #15: 0x00000001076c27f4 XUL`Parser::HandlePref(char const*, mozilla::PrefType, mozilla::PrefValueKind, PrefValue, bool, bool) + 84
frame #16: 0x000000010df1c334 XUL`prefs_parser::Parser::parse::h4ae053f32cdb7993 + 1684
frame #17: 0x000000010df1bc09 XUL`prefs_parser_parse + 185
frame #18: 0x00000001076c26a5 XUL`Parser::Parse(nsTString<char> const&, mozilla::PrefValueKind, char const*, mozilla::TimeStamp const&, nsTString<char> const&) + 85
frame #19: 0x0000000107691dc5 XUL`mozilla::openPrefFile(nsIFile*, mozilla::PrefValueKind) + 725
frame #20: 0x000000010769139f XUL`mozilla::Preferences::ReadSavedPrefs() + 143
frame #21: 0x0000000107690dbd XUL`mozilla::Preferences::InitializeUserPrefs() + 109
- At frame 13,
gCallbackPref
is assigned. - At frame 10, we launch socket process.
- At frame 9,
SharedPreferenceSerializer::SerializeToSharedMemory
andPreferences::EnsureSnapshot
are called. - In
EnsureSnapshot
, the arena for pref names is cleared. - At the end, the pref name of
gCallbackPref
is accessed and we have this crash.
I think clearing gCallbackPref
in Preferences::EnsureSnapshot
should be the right way to fix this.
Assignee | ||
Comment 7•4 years ago
|
||
Comment on attachment 9151438 [details]
Bug 1632881 - Clear gCallbackPref in Preferences::EnsureSnapshot, r=kmag
Security Approval Request
- How easily could an exploit be constructed based on the patch?: I'd say not easy. Given that the use-after-free is happened on the same stack, it's not easy to attach with this vulnerability.
- Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
- Which older supported branches are affected by this flaw?: 77
- If not all supported branches, which bug introduced the flaw?: Bug 1625151
- Do you have backports for the affected branches?: No
- If not, how different, hard to create, and risky will they be?: Socket process is only enabled on nightly, so this should not affect normal users.
- How likely is this patch to cause regressions; how much testing does it need?: Not likely. The patch is simple and I've verified this locally.
Updated•4 years ago
|
Comment 8•4 years ago
|
||
Comment on attachment 9151438 [details]
Bug 1632881 - Clear gCallbackPref in Preferences::EnsureSnapshot, r=kmag
sec-approval+
Comment 9•4 years ago
|
||
Looks like this needs rebasing around bug 1641438.
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
Looks like this needs rebasing around bug 1641438.
Thanks! I've rebased this patch.
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.
Please visit this google form to reply.
Assignee | ||
Comment 14•4 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #13)
As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.
Please visit this google form to reply.
Maybe I am not the best one to answer the questions, since I am not very familiar with the code in Preferences.cpp
.
Updated•4 years ago
|
Reporter | ||
Comment 15•4 years ago
|
||
Verified that I don't get the crash anymore using latest Nightly 79.0a1 and 80.0a1 on macOS 10.15 and 10.14.
Updated•3 years ago
|
Description
•