803806 - Local Privacy/Security vulnerability - Session Restore writes visited URLs, history, titles, referrers, and more to sessionstore.js (on exit), allowing prior session restoration even with all histories disabled&cleared and about:config set to disable SR.

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[sessionhistorybug]

Attachment: Buildconfig of clean installation of Firefox 16.0.1 with Privacy enabled and Session Restore "disabled"

Issue Summary:
A security/privacy vulnerability exists that could allow a local user to potentially determine what websites users have visited and have access to the URL, URL parameters, page titles, referrer information, history, and more. This vulnerability is due to closed window and tab information being written to sessionstore.js on browser exit.  This is normally expected/wanted behavior since Session Restore is a useful tool. Mozilla has released instructions for users to disable Session Restore for privacy and security purposes if desired, but these do not work to disable session restore (See websites referenced below)

This information can be gathered even if browser is set to NOT remember any browsing, download, search, and form history and about:config is properly set as per the websites below. Furthermore, this information can also be gathered even if a user clears entire browsing history before closing the browser (via the tools menu or CTRL+Shift+Del ). This occurs because sessionstore.js is written to when the browser exits normally (even when it should be disabled).

According to https://wiki.mozilla.org/Session_Restore#Privacy 
“Currently, the saved session data is cleared at shutdown, except in scenarios where the feature has been directed to intentionally save it, which are:
 • The application crashed 
• A forced restart, such as extension install or application update 
• The user has chosen to always resume sessions”

According to http://support.mozilla.org/en-US/kb/restore-previous-session#w_privacy-issues
“Session Restore may keep you logged in to sites that you were logged into before you closed Firefox. If someone else used your computer after you, they could access your account on these sites. If this is a concern then you should not configure Firefox to open all windows and tabs from your previous session.
 
You may also wish to disable the Session Restore crash recovery feature which is enabled by default. This will prevent restoring a previous session when Firefox is opened after an unexpected close or software crash.“ (by setting browser.sessionstore.resume_from_crash to false.

According to http://kb.mozillazine.org/Session_Restore 
Session Restore is completely disabled by doing the following:
1. In the Options menu, General tab: Do not set the homepage “Show my windows and tabs from last time”
2. Also ensure browser.sessionstore.resume_session_once is set to false
3. Set browser.sessionstore.max_tabs_undo and browser.sessionstore.max_windows_undo to 0.
4. Furthermore, browser.sessionstore.resume_from_crash can be set to false to disable the Session Restore crash recovery feature.

See also:
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#750 (Config settings relating to Session Restore)


Expected behavior:
Previous browsing sessions should not be recoverable if the above steps are taken to disable Session Restore. No data from the previous session should be written to sessionstore.js if Session Restore is disabled.  

Actual Behavior:
Previous browsing session can be restored by clicking “Restore Previous Session” in about:home or by “Restore Previous Session” in the History Menu. This is because the previous session’s data was written to sessionstore.js at the end of the previous session.
This occurs even if Session Restore is “disabled” by the steps outlined in the documentation.
This occurs even if the browser is set to “Use Custom settings for history” (In the Options menu, Privacy tab) with “Remember my browsing and download history” and “Remember my search and form history” unchecked.
This occurs even if a user clears the entire browsing history prior to closing Firefox (CTRL+Shift+Del).
Any user inputted text typed in the Location bar of any open tab at window close is also saved (even if it was not sent with the enter key.

Reproducibility: Always

Steps to reproduce:
1. Ensure that browser is NOT set to “Show my windows and tabs from last time” (Either through options or by setting browser.startup.page to 0 or 1).
2. Ensure browser.sessionstore.resume_session_once is set to false
3. Set browser.sessionstore.max_tabs_undo to 0
4. Set browser.sessionstore.max_windows_undo to 0
5. Set browser.sessionstore.resume_from_crash to false
6. (Optional: Delete existing sessionstore.js from profile folder)
7. (Optional: Set browser to not retain any browsing, download, forms, or search history, but do not enable private browsing)
8. Open Firefox to any webpage.
9. (Optional: Clear all browsing history with ctrl+shift+del or “Clear Recent History” in Tools Menu
10. Close Firefox normally (Not a crash close)
11. Check profile folder (%AppData%\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.default) to see a newly created/modified sessionstore.js. Open file to see the Session history of the browser when it was last closed. (Tabs with URLs, page titles, forward/back history, data typed by the user in the location bar, page referrers, etc)
12. Open Firefox
13. Navigate to about:home and click “Restore Previous Session” or click “Restore Previous Session” from the History menu.
14. The last window to be closed from the previous session (with tabs and back/forward history intact) is restored.
15. This sessionstore.js can be copied to the profile folder on a completely separate computer and restore a session.


System Configuration:
Microsoft Windows 7 Professional x64
Issue occurs on clean install of Firefox 16.0.1 the specific options set.
No Plugins, No Addons installed.
Your User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Firefox sync is not configured to sync anything.
About:buildconfig and prefs.js are attached for review.


Implications:
This problem has multiple privacy and security implications. There is the potential risk to leak of private information, such as server-session IDs, token parameters, or other parameters, that are used in a URL could be recovered by a malicious user if any copy of sessionstore.js is obtained. 

This may be surprising to a victim, especially if the browser was configured to not save browsing, download, form, or search histories and he/she thought that Session Restore was disabled after following Mozilla’s instructions. This is especially true considering that previous sessionstore.js files could potentially be recovered by any basic recovery software.

While this issue requires local access to a computer, (or malware infection), a malicious user could, in a trivial amount of time, access a public computer, “friend’s” computer, or business that uses Firefox and use portable Recuva or similar non-Admin-Requiring undelete software to search for all deleted sessionstore.js located in %AppData%\Roaming\Mozilla\Firefox\Profiles\xxxxxxxx.default

Recuva actually found a few hundred old sessionstore.js files on a business laptop that I had thought configured to disable session restore and save no browsing, download, search, and form history.  ~10 percent of those were recoverable, containing logs for a few hundred websites that could potentially be recovered and used by a malicious user.

Example 1:
User/Pass combinations can be saved to sessionstore.js if the tabs with the URI are open when browser is closed.  See Example1_Potential_UserPass_leaks_sessionstore.js
ftp://username:password@hostname/, http(s)://username:password@hostname/resource.ext, and mailto:[e-mail]?subject=Topic are all easily read from the file.

Example 2:
Page Titles and URLs by themselves can reveal a lot of personal information about a user. Even if a user logs out of accounts and clears browsing history at the end of his session!
See Example2_Detailed_Personal_Info_sessionstore.js for a more real-world example. 
In this file, you can clearly see my email address, email subjects, web searches, bank info.  You can also restore the session by copying that into your own Firefox profile. As an interesting aside, sharing or transfer of sessionstore.js files could possibly be a mechanism for virus/malware propagation if users Session Restore into a poisoned session, especially if the user automatically loads their last session.

Example 3:
Interestingly, anything typed into the Address bar by a user is saved in sessionstore.js, even if the user never presses the enter key or clicks on the arrow to go to a webpage or make a search through the awesomebar.
See User_Typed_Info_sessionstore.js


Further testing:
Session restore is partially disabled by following the instructions provided by Mozilla. A tab cannot be recovered with ctrl+shift+t if closed, so browser.sessionstore.max_tabs_undo;0 is working.  No data is flushed to disk in sessionstore.js while the browser is in use (regardless of browser.sessionstore.interval timing).  No writing occurs when the browser is forcefully terminated in Task Manager (so browser.sessionstore.resume_from_crash;false is presumably working).  Sessionstore.js seems to only be written when the browser exits normally (alt+F4, file->exit, the close button x).

Setting browser.sessionstore.privacy_level and browser.sessionstore.privacy_level_deferred to 2 does not fix this.
Manually setting the superseded browser.sessionstore.enabled to false does not change the behavior either.

Interestingly, about:sessionrestore gives the “Well, this is embarrassing.” message but does not list any recoverable windows or tabs (Even though they can be restored in the history dropdown menu.

Cause?
Only the last window’s tabs are saved to sessionstore.js.  If two windows are open, only the final window closed is saved to disk. 
If two or more windows are open and one is closed, that closed window can be reopened (with all its tabs) with the History menu -> Recently Closed Windows.
If multiple windows are open and several windows are closed, only the last window can be restored in this manner.

Perhaps browser.sessionstore.max_windows_undo is defaulting to 1 if a user tries to set it to 0, which causes one window to always be recoverable and the writing to sessionstore.js at browser close?


Current Workarounds:
Using custom settings for history with browsing, download, form, and search history disabled doesn’t prevent sessionstore.js from being created. However, using the browser in full private browsing mode successfully prevents creation/writing of sessionstore.js.
If a user does not save browsing or download history, but does not want to use private browsing (perhaps to keep all cookies from being deleted at close), choosing the option to “Clear history when Firefox closes” and selecting “Browsing History” in the Settings box also prevents sessionstore.js from being created or modified (even though the clearing the browsing history at exit shouldn't actually need to clear anything since it is set to not be saved)

Comment 1

[sessionhistorybug]

Attachment: Prefs.js file with the about:config changes that are supposed to disable Session Restore Completely

Comment 2

[sessionhistorybug]

Attachment: Example 1

Comment 3

[sessionhistorybug]

Attachment: Example2_Detailed_Personal_Info_sessionstore.js

Comment 4

[sessionhistorybug]

Attachment: Example3_User_Typed_Info_sessionstore.js

Comment 5

[sessionhistorybug]

Attachment: Example1_Potential_UserPass_leaks_sessionstore.js

Comment 6

[sessionhistorybug]

The bug is unchanged in Firefox 17 Beta 1 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0) (http://hg.mozilla.org/releases/mozilla-beta/rev/6b83222781e3)

The bug also persists in the Firefox 19 nightly (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ) (Built from http://hg.mozilla.org/mozilla-central/rev/ff4af83233dc)

Comment 7

[Daniel Veditz [:dveditz]]

I haven't investigated to see if there's some other combination of prefs, but there needs to be a way to completely disable writing to sessionstore.js for users who need it.

Do we write to sessionstore.js in Private Browsing mode? If not we should be able to use whatever hooks that's using. If we do that's probably a PB bug.

Comment 8

[David Teller [:Yoric] - still alive but not very active]

(In reply to Daniel Veditz [:dveditz] from comment #7)
> I haven't investigated to see if there's some other combination of prefs,
> but there needs to be a way to completely disable writing to sessionstore.js
> for users who need it.
> 
> Do we write to sessionstore.js in Private Browsing mode? If not we should be
> able to use whatever hooks that's using. If we do that's probably a PB bug.

Currently, we don't touch sessionstore.js in Private Browsing mode (the change that ensured this landed on March 27, 2014).

Comment 9

[David Teller [:Yoric] - still alive but not very active]

If someone has a clear idea of the list of preferences that should determine that we don't write sessionstore.js, I can mentor a bug to make this happen.

Comment 10

[Daniel Veditz [:dveditz]]

Re comment 0, the wiki is old (but can be fixed), mozillazine is an outdated community site, and the sumo article is plain wrong and should be fixed.

(In reply to David Rajchenbach Teller [:Yoric] from comment #9)
> If someone has a clear idea of the list of preferences that should determine
> that we don't write sessionstore.js, I can mentor a bug to make this happen.

The prefs we do have cover a lot (too many?) of ways to reduce the information stored there. The reporter got many of them but missed setting browser.sessionstore.max_serialize_back and browser.sessionstore.max_serialize_forward to 0. Those settings work great -- session history is still available while you're browsing but goes away when you shut down and I'd argue those should be the default settings.

The max_tab/window_undo prefs are more annoying: if you don't save them in sessionstore then you don't get those features while you're actively browsing; there's no memory-only equivalent.

The one pref we do not have is 

   browser.sessionstore.enable

that would disable the whole thing, including the remnant bits left after shutting down the existing prefs as much as possible. Given the SUMO article (and this bug) clearly people are asking for that, but SUMO is quite wrong about what the resume_from_crash pref does. Maybe it was true once, but since sessionrestore powers other features (like undo tab) it only controls whether we auto-restore after a crash, not whether we save it in the first place.

Incidentally, browser.sessionstore.cleanup.forget_closed_after is set to 2 WEEKS -- isn't that a little excessive? if you really needed that window after that long it should still be in your history, right? You don't need to be able to "oops, undo tab" after that long!

Comment 11

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue using 93.0a1 (2021-08-30) but unfortunately I wasn't able. I think this issue is no longer valid for the latest firefox versions. As per this comment I will close this issue.
If this issue is still available and you are able to reproduce it please feel free to reopen it.

Have a nice day!