1878578 - (CVE-2024-38312) Firefox on iOS - Private Browsing Security Bug

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[4n6focus]

Attachment: FirefoxTesting.7z

There are many general and functional related bugs reported on github for iOS Firefox but since this is a security issue I wanted to check if this should be disclosed privately first. Can you please see the below and let me know?

Steps to reproduce

First Test

1. Launch the Firefox app and start a “Private” browsing session.
2. Browse to any website. In this test, Duckduckgo[.]com was used.
3. Generate browsing activity. In this test a DDG search was performed and refreshed.
4. Close the private mode browsing tab.
5. Close the Firefox app.
6. Make basic iTunes backup of the iPhone.
7. Firefox user data located in “org.mozilla.ios.Firefox”. This contains the folder "/profile.profile/" that contains two subfolders

• "/TabManagerScreenshots/" contains image files that are screenshots of the private browsing sessions.
• "/tab-session-data/" contains files with names “tab-“ followed by 32 digit hex strings with 4 hyphens between the strings. Inside these files are the actual URLs that the user was browsing.

These files are persisting despite it being a “private” session that should not store logs or records of the browsing activity.

Second test
8.Repeat steps 1 through 3 to generate additional activity.
9. Go into the Firefox App’s Settings menu. Select “Data Management”. “Browsing History,” “Cache,” “Cookies,”, and “Offline Web Site Data” are selected. Then select “Clear Private Data”.
10. A pop-up appears that warns that “this action will clear all of your private data. It cannot be undone.” Select “OK” to proceed.
11. While still in “Data Management,” select “Web Site Data,” and then touch “Clear All Web Site Data.” A pop-up appears that warns “This action will clear all of your web site data. It cannot be undone”.
12. Repeat step 5 and 6.
13. The artifacts observed in step 7 remain.

Expected behavior

• Firefox states that while in Private browsing mode, browser logs should not be retained on the device.
• Attempts to manually clear browser artifacts/logs and caches in the settings menu should result in purging these artifacts from the device.

Actual behavior

• Closed or manually cleared private browsing history is not visible to the user but Firefox retains many artifacts associated to the user’s Private browsing activity on the device. These include screenshots of the websites and plists containing potentially sensitive data including verbose logs of the search queries made, the URLs that they browsed, and the dates/times of this activity.
• This could result in disclosure of a user's historical private browsing history (that they thought would have been destroyed) to 3rd parties and presents security and privacy risk.

Device & build information

• Device: iPhone 12, iOS 17.3
• Build version: 122.1
• First seen version: New

Comment 1

[lmarceau]

Adding notes on top of the issue:

Multiple mechanism are implied in the above conversation. There's mention of logs, cookies, session data, caches, browsing history and website data. Those are all distinct, and are treated differently at the moment in the app (not saying this is right or wrong, just that they are very different things from the code perspective, and treated differently).

Data management settings section currently enables the user to delete: browsing history, cache, cookies, website data, tracking protection and downloaded files, but not session data. Tab data (or session data) in itself is different from those, as by default private tabs are in fact indeed stored on local device storage. We do have an option to "Close private tabs when leaving private browsing" under the settings but from the current ticket, I understand this can be missed or misinterpreted by users.

Comment 2

[4n6focus]

Hi
I understand what you’re saying but I think the problem isn’t so much a misinterpretation by the users, but a problem with how Firefox handles its data.

The purpose of a private mode is so you can have a browsing session that doesn’t retain persistent artifacts (e.g. history, cookies, etc.). This could be for a variety of reasons from web dev work, privacy, security or personal safety, and so on. Firefox for iOS even describes the following:

“Private Browsing does not save history, cookies, passwords, site preferences, or temporary Internet files.”

Unfortunately, Firefox is not only retaining much of the above data, but is doing so in a manner that the user cannot see and has no knowledge of. What makes this worse is the behavior of Firefox in the settings menus. It tells the user that “all private data” will be deleted, yet these sessions files that effectively contain much of their actual browsing logs, remain persistent on the device.

There is a bug with how Firefox handles that data purging. Unless that changes, it poses a significant security and privacy risk to its users.

Comment 3

[lmarceau]

Hello! Could you indicate to us where you see the sentence “Private Browsing does not save history, cookies, passwords, site preferences, or temporary Internet files.” ? I was searching it in the app and haven't found it.

Also, I opened a ticket to fix how we manage our tab history whenever we delete browsing history from the Data management setting page under Tab.swift. We've recently changed how sessionData is persisted, and there's an improvement there to make to ensure that data is deleted whenever the user selects their data to be deleted. I don't think this is a security issue per se, as to get ahold of that local tab data stored on disk would be required for an attacker to get their hands on the physical device of the user. Unless I am mistaken, let me know!

Comment 4

[4n6focus]

Hi there,

It is excellent to hear about the updates and that sure was fast.

Regarding the quote I referenced - in the Firefox iOS app, first toggle private mode. It looks like the image starting with "A" that I uploaded just now. In there is an excerpt about how Firefox will not remember history. Below that text is a purple link "Learn More". Click that and it leads to the Mozilla support website: https://support.mozilla.org/en-US/kb/private-browsing-firefox-ios . Screenshot "B" shows the quote that I was referencing.

I think it is a security issue for a few reasons and largely focused on the confidentiality aspects. Requiring physical access may help mitigate some risk, but it is still there and can be compromised via a variety of ways, including without physical access to the phone (more detail on that below).

Several browsers have a private browsing mode specifically to help protect the confidentiality of a user’s browsing activities. Firefox on Windows and Linux platforms, for example, destroys private artifacts reliably and that is to protect the confidentiality of the browsing activity (regardless of physical access to the device or not). Imagine if it was found, for example, that Firefox on Ubuntu is saving screenshots and logging private browsing session info to a hidden area on their hard drive and without them knowing. I think that would broadly be seen as a significant security issue impacting privacy/confidentiality. Moreover, it may be safe to say that many users select Firefox over competing browsers for two primary security-related reasons: privacy (confidentiality) and Mozilla's history of instilling trust (e.g., Moz's 'Privacy promise'). In the current build of iOS Firefox, it is telling the user that it is not storing this data when it is, and that raises concerns with both of the above security aspects.

Back to this bug specifics - physical access is not necessarily required to recover these private mode browser artifacts. These items are stored on the device's storage and within backups- backups that are often on PCs, portable hard drives, or cloud storage. This means that compromise of the PC, drives, or cloud storage (e.g. theft, malware infection, malicious or snooping user, etc.) could result in access to a Firefox user's private browser activities that they thought were never stored.

Another scenario could be where someone relinquishes their phone, with the belief that whatever they were browsing or whomever they may have been communicating with in Firefox private mode was purged long ago (perhaps expecting exact similar private mode behavior of Firefox across Linux, Windows, iOS, Android). But it turns out that the browser activity is still there and recoverable... Such a scenario could be an eavesdropping family member, a thief, a lost device, reselling a phone, an oppressive regime seizing a reporter or political rival’s cell phone, and so on.

Yet another scenario could be for when the next Checkm8 is found, and malware or otherwise exploits it to gain access to user app data. Data retention of persistent Firefox private mode data could be recoverable and potentially highly impactful to the user.

In my opinion, regardless of which example scenario above, the persistent retention of these artifacts in a hidden yet easily recoverable manner is significant and would fall under a confidentiality security vulnerability.

Comment 5

[4n6focus]

Attachment: A - Firefox App - 'Firefox wont remember'.png

Comment 6

[4n6focus]

Attachment: B - 'learn more' - Mozilla Website Firefox For iOS Screenshot.PNG

Comment 7

[4n6focus]

Hi Mozilla,

It has been a couple weeks and I figured I would check to see if there are any updates to the security bug I reported. Could you please let me know?

Comment 8

[lmarceau]

There is no update apart from the conversation we had above. Thank you!

Comment 9

[4n6focus]

Thanks, lmarceau.

Do you know what the next steps are in terms of this report? I can imagine that Mozilla is reviewing various bugs and prioritizing them accordingly, but I am curious about where this one may go from here. The status shows as unconfirmed, but I am not sure where that will go.

I have reported this security bug discreetly and in good faith, with the goal of protecting Mozilla users and giving all the time needed to address it. I will continue to handle it discreetly for as long as needed, but I am also interested in what to expect. As it is a privacy & security issue, I believe it has a flag for bug bounty. I am interested in Mozilla's take on that as well.

Comment 10

[lmarceau]

For bug bounty, the right persons to contact are [e-mail], thank you!

Comment 11

[mreagan]

I noticed there was a follow-up email sent regarding this and just wanted to mention that I'm reviewing the ticket and also taking a closer look at the current iOS client behavior and running a few tests. I'll be sure to update as soon as I have more information. Thank you!

Comment 12

[mreagan]

Just wanted to add some additional context and comments here. Based on what I can see from the original report and the discussion above it sounds like the primary concern is that tabs (including Private ones) result in residual browsing data within the app bundle that is not removed, specifically tab session data files and tab screenshots. For screenshots, in my testing I can see that the client does properly clean these up for closed private tabs, however it happens on subsequent launches as part of general housekeeping that the client application does during its startup. For tab session files a change has been added to also clean these up (at the same time as screenshots) during app launch. At some point a more robust solution might be implemented to clean up these files more aggressively (immediately upon tab closure) but that is likely to be a more involved code change.

I wanted to be sure to clarify, however, that the data discussed above for the tabs is only stored locally within the app container, it is not ever sync'd or sent across the wire AFAICS. As a result there is not really any way for an attacker or malicious user to gain access to this data without breaking into and gaining full access to the user's phone. A user can of course create a backup of their phone data and then give that to someone, which could potentially include sensitive information, but that is true of most apps on the device (since the backup will typically include the support files for all apps on the device).

I believe this ticket will likely be kept open for a bit longer as the iOS team is re-evaluating potential changes to how Private tabs work in the iOS client, which could impact this. Please let me know if there are any questions in the meantime. Thank you!

Comment 13

[Andrew McCreight [:mccr8]]

(In reply to mreagan from comment #12)

I wanted to be sure to clarify, however, that the data discussed above for the tabs is only stored locally within the app container, it is not ever sync'd or sent across the wire AFAICS. As a result there is not really any way for an attacker or malicious user to gain access to this data without breaking into and gaining full access to the user's phone. A user can of course create a backup of their phone data and then give that to someone, which could potentially include sensitive information, but that is true of most apps on the device (since the backup will typically include the support files for all apps on the device).

Yes, that is right. At least on Firefox desktop, I believe the goal is that data from a private browsing session never reaches the disk, so no data will be exposed even if the browser crashes in the middle of a session.

Comment 14

[4n6focus]

Hi Moz team,

Thanks for continuing to look into this.

Presumably, Firefox for iOS may have to cache some data to disk due to memory constraints. iOS devices often have relatively low RAM capacities compared to Android devices and certainly low compared to desktops. Outside of something similar to a pagefile in a Windows environment, Firefox private browsing activity seems to almost exclusively live out of volatile memory and there are significant and long-lasting security benefits to this. What is odd to me, and something providing for an inconsistent user experience, is that this persistent private mode in Firefox for iOS appears to be by design and an outlier compared to Firefox browsers on other platforms. Persistent private browsing mode is not present in desktop variants or even on other mobile Firefox variants - Firefox for Android seems to behave very similarly to desktop-based Firefox applications with destruction of browser artifacts at application termination.

It is also important to note that potentially the single biggest benefit of why Firefox (and other browsers) private mode on desktop platforms do not cache files to disk is to reduce exposure surface and ensure these artifacts are not easily recoverable by malicious activity - it could be a malicious user or processes that conducts this activity at a later time & after the browsing session. Not retaining data is one of many defensive mechanisms. Mobile devices have their own challenges (e.g., RAM constraints), and may necessitate some disk caching to the app container, but that is even more reason why aggressive cleanup and/or encryption should be leveraged. Perhaps this is the potential more robust solution you alluded to.

Regarding data over the wire, I think there are some aspects to consider there. Firefox for iOS does not appear to be sending private browsing data over the wire via Mozilla’s sync services but the behavior of storing it within the app container means that it syncs over the wire via other services, such Apple iCloud backups. This gets back to the above, with the need for Firefox to have inherent defensive behaviors with cleanup as best as possible regardless of a given platform’s risks. If Firefox does not, crucial, and sensitive browsing data is replicated all over the place (including over the wire). This is data that users thought was purged either by traditional/expected Firefox behavior (again back to expecting like-behavior transcending Firefox applications across platforms and the application’s and website messages saying the browser artifacts were purged).

In any case, breaking into the phone is not necessarily required to abuse this bug. A malicious entity would just need a backup of the phone. This harkens back to all the above – I think one of the biggest benefits of private browsing that many Firefox users leverage is to reduce their footprint and data traces. Less data and logs often correlate to more privacy and less risk. When Firefox is writing all of this to disk in he clear, it is expanding user’s exposure greatly and leaving a trail of potentially sensitive artifacts sprinkled around - the physical device, iTunes backups (which are often replicated to numerous other areas such as HDDs, cloud storages, etc.), backups to iCloud ( which are rather ubiquitous for compromise), and I think illustrates the need to limit data retention wherever possible for private browsing.

Comment 15

[mreagan]

PR https://github.com/mozilla-mobile/firefox-ios/pull/19936/ should resolve the final remaining issues with the private tab session data (which are now not persisted at all). The screenshots, as noted before, should already be cleaned up, though that happens on subsequent launches as part of the app's general housekeeping.

Related JIRA for this ticket: https://mozilla-hub.atlassian.net/browse/FXIOS-8672

Comment 16

[4n6focus]

Good news. Thanks for the update, Matt. I am still interested in understanding Mozilla's take on this report for recognition and bounty eligibility.

Comment 17

[mreagan]

For questions on the bounty eligibility can you please reach out again to [e-mail]? If you have trouble getting your questions answered there let me know and I can try to help further.

Comment 18

[Daniel Veditz [:dveditz]]

What is odd to me, and something providing for an inconsistent user experience, is that this persistent private mode in Firefox for iOS appears to be by design and an outlier compared to Firefox browsers on other platforms.

All browsers on iOS devices are required by Apple to use the native browser engine for the part that loads and displays web pages. There are many ways in which the iOS version of Firefox differs from Firefox on other platforms because it's heart has been ripped out and replaced with apple.

Comment 19

[mreagan]

Attachment: advisory.txt