Closed Bug 1632881 Opened 4 years ago Closed 4 years ago

Crash in [@ libsystem_platform.dylib@0x817]

Categories

(Toolkit :: Startup and Profile System, defect)

77 Branch
All
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla79
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)

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

  1. Start firefox with -migration parameter
  2. Select to import from another browser
  3. 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.
Flags: needinfo?(kershaw)
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
Regressed by: 1625151

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.

Mark this as sec-high, since this is a UAF bug.

Here is what I found:

  1. We tried to launch socket process since a pref is changed.
  2. The pref name is released in Preferences::EnsureSnapshot.
  3. 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?

Flags: needinfo?(kershaw) → needinfo?(kmaglione+bmo)
Keywords: sec-high

(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.

Group: firefox-core-security
Assignee: nobody → kershaw
Status: NEW → ASSIGNED

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
  1. At frame 13, gCallbackPref is assigned.
  2. At frame 10, we launch socket process.
  3. At frame 9, SharedPreferenceSerializer::SerializeToSharedMemory and Preferences::EnsureSnapshot are called.
  4. In EnsureSnapshot, the arena for pref names is cleared.
  5. 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.

Flags: needinfo?(kmaglione+bmo)

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.
Attachment #9151438 - Flags: sec-approval?

Comment on attachment 9151438 [details]
Bug 1632881 - Clear gCallbackPref in Preferences::EnsureSnapshot, r=kmag

sec-approval+

Attachment #9151438 - Flags: sec-approval? → sec-approval+

Looks like this needs rebasing around bug 1641438.

Flags: needinfo?(kershaw)
Attachment #9151438 - Attachment description: Bug 1632881 - Clear gCallbackPref in Preferences::EnsureSnapshot → Bug 1632881 - Clear gCallbackPref in Preferences::EnsureSnapshot, r=kmag

(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)

Looks like this needs rebasing around bug 1641438.

Thanks! I've rebased this patch.

Flags: needinfo?(kershaw)
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

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.

Flags: needinfo?(kershaw)
Whiteboard: [sec-survey]

(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.

Flags: needinfo?(kershaw)
Flags: qe-verify+
Whiteboard: [sec-survey] → [sec-survey][post-critsmash-triage]

Verified that I don't get the crash anymore using latest Nightly 79.0a1 and 80.0a1 on macOS 10.15 and 10.14.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: