Closed Bug 1849186 (CVE-2023-6872) Opened 8 months ago Closed 5 months ago

Browsing history leaked to syslogs via GNOME

Categories

(Firefox :: Private Browsing, defect, P1)

Firefox 102
Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
121 Branch
Tracking Status
firefox121 --- fixed

People

(Reporter: richard, Assigned: pierov)

References

(Regressed 1 open bug)

Details

(4 keywords, Whiteboard: [adv-main121+])

Attachments

(2 files)

Tor Browser devs have received this bug report from user @honorton:

Summary

Tab titles are sometimes logged by GNOME to /var/log/syslog, effectively causing browsing habits to persist on the system, even after closing Tor Browser. As Tor Browser does not save history by default, many users will not expect this.

Steps to reproduce:

  1. Open a new Tor Browser window.
  2. (optional) "Connect" to the Tor network and navigate to an arbitrary website.
  3. Press the Super key (default) to open the GNOME activities menu.
  4. Review syslog via cat /var/log/syslog | grep -i "browser"

What is the current bug behavior?

I see results containing Tor Browser tab titles, such as the titles of opened websites.

What is the expected behavior?

I expect not to see my visited website titles in any system file without my authorization.

More strongly, I don't expect GNOME (which may log all sorts of things) to require access to my visited website titles.

Environment

  • OS Version: Pop! OS 22.04
  • GNOME Shell Version: 3.38.6
  • Tor Browser Version: 12.5.2
  • Tor Browser Installation Method: "Linux" binary from https://www.torproject.org/download/

Relevant logs and/or screenshots

[/var/log/syslog]
[snip]
Aug  9 11:23:52 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug  9 11:23:53 pop-os gnome-shell[2864]: Couldn't find child [0x5558d69f7880 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("cute cats at DuckDuckGo — Tor Browser")] in window slots
Aug  9 11:27:28 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
Aug  9 11:27:31 pop-os gnome-shell[2864]: Couldn't find child [0x5558da9ea870 Gjs_ui_windowPreview_WindowPreview:first-child last-child ("[Wayland] [3.38.3] Shell freezes/stops reacting to most input (#3706) · Issues · GNOME / gnome-shell · GitLab — Tor Browser")] in window slots
[snip]

Our best idea so far would gate setting the window title to the webpage title behind private browsing mode.

Presumably, it ends up in your syslog via GNOME sending its stdout/stderr to systemd-journald, or something along those lines. From Firefox's perspective, the only thing happening is it printing some messages to stdout or stderr. (not trying to discredit the report, just describing the mechanics)

I'll add this: I don't think we ever thought about stdout/stderr being a potentially permanently stored medium. It's new(ish) that it ends up in syslog, although I think we've had reports about Firefox's logs ending up in $HOME/.xsession-errors, which at least was user-specific, not that it's any less accessible to the root user. (I think .xsession-errors used to be reset each time X or a desktop session started, though).

This is also interestingly a platform-dependent problem. I'm fairly sure stdout/stderr doesn't end up anywhere on Windows. I think it ends up in /dev/null on macOS, but I'm not certain of it.

(In reply to Mike Hommey [:glandium] from comment #1)

Presumably, it ends up in your syslog via GNOME sending its stdout/stderr to systemd-journald, or something along those lines. From Firefox's perspective, the only thing happening is it printing some messages to stdout or stderr.

I don't think Firefox is doing anything actively here. We redirect its standard output and error to /dev/null by default.
I think this leak was caused by gnome-shell itself, which was reporting that error formatted with the window title.
I think Firefox could keep the generic default title on PBM windows (I mean browser-main-window-window-titles.data-title-private from browser.ftl) to avoid similar cases. This problem seems similar to the generic "Firefox is playing media" notification you get instead of the actual page title in PBM.
Maybe would it be possible to enable/disable this behavior with a preference, if it is too disruptive for the majority of users?

I think this leak was caused by gnome-shell itself

Oh right, if it were Firefox, it would be saying firefox.desktop instead of gnome-shell!

The severity field is not set for this bug.
:timhuang, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(tihuang)

Maybe would it be possible to enable/disable this behavior with a preference, if it is too disruptive for the majority of users?

I would review a patch that did this behind a preference.

Assignee: nobody → pierov
Attachment #9357478 - Attachment description: WIP: Bug 1849186 - Add a preference not to expose the content title in the window title. r?gijs → Bug 1849186 - Add a preference not to expose the content title in the window title. r?Gijs

Dan, do we need to keep this sec-sensitive? I assume not... but you didn't open it up when marking it sec-vector. :-)

Severity: -- → S3
Flags: needinfo?(tihuang) → needinfo?(dveditz)
Priority: -- → P1
Group: firefox-core-security
Flags: needinfo?(dveditz)
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/840d16ce4247
Add a preference not to expose the content title in the window title. r=Gijs,tabbrowser-reviewers,dao
Regressions: 1864485
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch
Whiteboard: [adv-main121+]
Attached file advisory.txt
Keywords: sec-low
Alias: CVE-2023-6872
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: