1849186 - (CVE-2023-6872) Browsing history leaked to syslogs via GNOME

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect, P1)

Description

[morgan (Tor Project)]

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.

Comment 1

[Mike Hommey [:glandium]]

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)

Comment 2

[Mike Hommey [:glandium]]

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.

Comment 3

[Pier Angelo Vendrame]

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

Comment 4

[Mike Hommey [:glandium]]

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!

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit BugBot documentation.

Comment 6

[:Gijs (he/him)]

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.

Comment 7

[Pier Angelo Vendrame]

Attachment: Bug 1849186 - Add a preference not to expose the content title in the window title. r?Gijs

Comment 8

[:Gijs (he/him)]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
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

Comment 10

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/840d16ce4247

Comment 11

[Jason Kratzer [:jkratzer]]

Attachment: advisory.txt

Comment 12

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons