2017666 - (CVE-2026-4712) incorrect private browsing status for native Cocoa windows

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Josh Aas]

The last argument in the following function communicates whether the window is used for private browsing:

nsresult nsCocoaWindow::CreateNativeWindow(const NSRect& aRect,
                                           BorderStyle aBorderStyle,
                                           bool aRectIsFrameRect,
                                           bool aIsPrivateBrowsing)

This is how that is handled:

  // Make sure that window titles don't leak to disk in private browsing mode
  // due to macOS' resume feature.
  mWindow.restorable = !aIsPrivateBrowsing;
  if (aIsPrivateBrowsing) {
    [mWindow disableSnapshotRestoration];
  }

Note that mWindow.restorable is the inverse of private browsing. A window should not be restorable if it is for private browsing.

Now look at what happens in nsCocoaWindow::HideWindowChrome:

  // Recreate the window with the right border style.
  NSRect frameRect = mWindow.frame;
  BOOL restorable = mWindow.restorable;
  DestroyNativeWindow();
  nsresult rv = CreateNativeWindow(
      frameRect, aShouldHide ? BorderStyle::None : mBorderStyle, true,
      restorable);

This function is attempting to create a new native window based on the previous one. Unfortunately, the last argument it passes to communicate private browsing status is mWindow.restorable. This should be the inverse.

Private browsing windows become non-private, and non-private windows become private. This can leak information about private browsing windows to disk.

Comment 1

[Josh Aas]

Attachment: (secure)

Comment 2

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 639707

Comment 3

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 639707

Comment 4

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 639707

Comment 5

[Stephen A Pohl]

Comment on attachment 9546164 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: There is a potential of leaking private information to disk due to the fact that non-private browser windows are opened when a user expects them to be private.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: I have modified the commit message, but a careful and educated look at the patch could reveal the issue.
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: All and yes.
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: Should apply cleanly, or can easily be adjusted.
• How likely is this patch to cause regressions; how much testing does it need?: Highly unlikely.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: No

Comment 6

[Haik Aftandilian [:haik]]

Is the private browsing leakage limited to situations where native fullscreen is disabled (full-screen-api.macos-native-full-screen=false)?

Comment 7

[Josh Aas]

(In reply to Haik Aftandilian [:haik] from comment #6)

Is the private browsing leakage limited to situations where native fullscreen is disabled (full-screen-api.macos-native-full-screen=false)?

I believe this is the case.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7aafffd94a32
https://hg.mozilla.org/integration/autoland/rev/9d9959534641
Improve native Cocoa window creation. r=mac-reviewers,bradwerth

Comment 9

[Daniel Veditz [:dveditz]]

Comment on attachment 9546164 [details]
(secure)

sec-approval not required for sec-moderate or sec-low bugs

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/9d9959534641

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR140 uplift when you get a chance.

Comment 12

[Brad Werth [:bradwerth]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D283899

Comment 13

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Window restore of private windows will be restored as normal (non-private) windows.
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Corrects a single boolean parameter.
• String changes made/needed: None.
• Is Android affected?: no

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/a6482a418330

Comment 15

[Josh Aas]

There is a request for info from me here but I'm not sure what input is needed. Are you asking my opinion about uplifting to ESR 140? If so, I think others are more qualified than me. I'm not sure what the standard criteria are.