sensitive data in crashdumps was an unwelcome surprise; crash reporter dialogs not clear enough for informed consent
Categories
(Toolkit :: Crash Reporting, task)
Tracking
()
People
(Reporter: jan-bugreport, Unassigned)
References
Details
(Keywords: reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Hi,
while migrating data to a new Firefox profile, I noticed the .dmp files under ~/.mozilla/firefox/Crash Reports/pending. Running strings on them revealed that one of the files contained authentication cookies (if I had to guess based on surrounding data, I'd say probably as part of the HTTP request headers stored with a cache entry).
This is extremely concerning, as the user-facing UI does not warn the user that such sensitive data could be uploaded as part of the crash reports. The crash report dialog lets the user select whether to "Include the address of the page I was on", which I naively interpreted as "the URL is the most sensitive data that could be contained in the crash report, and only if I choose to do so".
Looking at the "Details", the dialog shows only non-sensitive data, and a vague statement that "This report also contains technical information about the state of the application when it crashed."
Developer facing documentation confirms that these reports do contain sensitive data like memory dumps: https://crash-stats.mozilla.org/documentation/protected_data_access/
The privacy policy would vaguely inform users about this (https://www.mozilla.org/en-US/privacy/firefox/#crash-reporter) but it is not linked from the crash reporter dialog (and even if it was linked, something like this should be readily apparent, not hidden in a policy).
I understand that you may need the crash dumps to investigate certain more complicated crashes, but there should be a clear warning that such data can in some cases include authentication credentials, and make the dumps optional. The current dialog misleads users into thinking that there is no sensitive data included in bug reports, while potentially uploading the most sensitive kind of data that Firefox has access to.
(Ironically, the crashes I've been experiencing for years when closing Firefox seem to be linked to the "delete site data on exit" setting, and seem to have prevented Firefox from deleting web sites' session storage on close despite it being configured to do so.)
Cheers,
Jan
PS: I've also sent this to security@ from a different e-mail address (same subject). The autoresponse asked me to file a bug.
|
||
Updated•3 years ago
|
|
||
Comment 1•3 years ago
|
||
We might need UX/UI input for this. Changing the browser crash reporter dialog is tricky business, but changing the tab crashed UI should be rather easy and that's what users encounter more often.
|
||
Comment 3•3 years ago
•
|
||
copying over willkg's comment from the dupe bug 1733630 comment 1 :
We've got multiple crash reporter clients across our products and I think they've got different text. When I removed the Email field earlier this year, I was talking with Nneka and Emily about this and I think the intention was to go through all the crash reporter clients and check the text the user is seeing and agreeing to when sending crash reports. Then based on that audit, we'd go through and make the changes required.
I think work on this bug should involve input from Trust and Privacy.
|
|
||
Comment 4•3 years ago
|
||
Hi Jan -- which file did you run the strings command on? When we crash we create a .dmp file and a .extra file. The "Details" tab should be the stuff in .extra, which is a JSON blob of metadata about the build and environment. No cookies, but does contain the user's list of installed extensions which might be sensitive to them, and optionally the URL it crashed on if the user checked that box.
The .dmp file is the "technical information about the state of the application when it crashed". This is produced by our fork of Chrome's crash reporter code and does not intentionally grab cookies. Some chunks memory involved in the crash are preserved for debugging. If you crashed in the middle of a network operation there might be some cookies in there incidentally, or they might appear as leftovers in an uninitialized buffer. This will also be true of dumps from Chrome's crash reporter, and really, any kind of crash dump.
Access to the raw .dmp files is tightly restricted, as is access to the machines that process them to create the reports on https://crash-stats.mozilla.org/
It was the dump file, as I mentioned. While I understand why these dumps are helpful, that they do not intentionally grab cookies or passwords, that you're restricting access to the data, and that this is done with good intent, I don't think it is acceptable for a privacy-focused product to upload such dumps without getting informed consent from users.
Especially due to the vague nature of data visible in the details view and the checkbox allowing users to remove the currently open URL from the report, the current dialog makes users think that nothing sensitive is being sent. (As you'll hopefully agree, the web site URL is less sensitive than the worst-case scenario of what can be in the crash dump, like session cookies, passwords, or private message content.)
The way Chrome gets consent from users is IMO far from a good example of how it should be done, but the dialog at least contains a "Learn more" link leading to https://support.google.com/chrome/answer/96817, which provides clear examples of the most sensitive data that can leak this way:
What these reports include
If Chrome crashes, some personal information might be included in the report. These reports have:
- Memory related to the crash, which may include page contents, payment information, and passwords
...
Given that Firefox is trying to be the more privacy-respecting alternative, I think it would be appropriate to have a clear warning directly in the dialog. Yes, this will mean fewer users will send reports, but I hope Mozilla doesn't want reports from users that had to be tricked into agreeing to send them. (I was also disappointed to see that Firefox enables telemetry by default unless the user actively goes and disables it; Chrome at least seems to pop up a dialog with two checkboxes on first start, at least on Linux, and IIRC on Windows it lets you make that choice when downloading the installer.)
For me personally, as a privacy conscious power user who understands what a memory dump means, this felt like a huge breach of trust. I reviewed the dialog, and submitted the crash report because I assumed (based on the visible information) that nothing sensitive would be uploaded (that e.g. at worst a client-side generated stacktrace equivalent would be uploaded, but not random raw memory content). I don't think many people would expect "technical information about the state of the application" to mean "potentially your passwords or private messages".
|
|
||
Comment 6•3 years ago
|
||
The quoted Chrome language is very similar to ours. from our Privacy Policy:
Sensitive data: Crash reports include a ‘dump file’ of Firefox’s memory contents at the time of the crash, which may contain data that identifies you or is otherwise sensitive to you.
...
Technical data: Crash reports include data on why Firefox crashed and the state of device memory and execution during the crash.
(And then links right to the technical documentation, which is probably skipping a gear for most readers.)
Each new user is presented with the privacy policy open in a tab. The checkbox for submitting crash reports in preferences also has a "learn more" link to that section of the privacy policy. You're right that it would make sense to include such a link on the crash dialogs themselves. The actual data we collect is only sometimes and accidentally sensitive, and squarely in line with other apps (and operating systems) that have crash reporters.
I'm going to take the security flag off this bug so the appropriate UI folks can see it. This is the expected (by us) and documented behavior and keeping it hidden is not protecting users. Rather, we failed to live up to our "No Surprises" Data Privacy Principal in your case and need to figure out better ways to communicate what's collected. I have changed the bug summary to better describe the desired change; if I didn't capture the issue correctly please let us know!
Note that there are at least two different crash dialogs. The reporter is describing the standalone window you get when the whole browser crashes, which is not a great time to offer a "Learn more" link. Could beef up the description of what "technical information" means in the text at the bottom of the "Details" window, perhaps by grabbing the "Sensitive data" line from our privacy policy (which might cut down on localization burden). The "tab crashed" one tells the user even less, does not have a "Details" button but could easily support a "Learn more" link to the privacy policy. You could argue the lack of "Details" is actually good here -- users know they have to look elsewhere for what might be in there and can't be misled into thinking it's a complete picture.
These two different dialogs can be seen by opening the test urls about:crashcontent (tab crashed page) and about:crashparent (warning: does what it says!)
I was also disappointed to see that Firefox enables telemetry by default unless the user actively goes and disables it;
That's a bit off-topic for this bug and I respectfully refer you to the coverage and discussions that arose when we made that controversial change sometime early-mid 2020. The default privacy policy tab for new users starts off with the telemetry section, and has a button that will take you right to the section in preferences where you can turn it off (which doesn't satisfy everyone, but at least there's that much). The data gathered is not personal browsing data -- you can see all the data we collect by opening the page about:telemetry.
Thank you. I agree that the new summary captures the issue well.
I think the privacy policy language would also benefit from changes: "identifies you or is otherwise sensitive to you" will make people think of names, e-mail addresses and visited URLs, not passwords. The Chrome language is much clearer.
|
|
||
Comment 8•3 years ago
|
||
It's worth noting that implementing any changes to the crash reporter dialogs can be easy but or they can be very complicated depending on what we're talking about. The in-browser "this tab has crashed" one or the infobar submission button - both of which deal with child process crashes - are trivially simple to update. They're just chunks of HTML and clearing the wording or adding a link to them is very easy. The browser crash reporter dialog is a very different beast. Changing the wording is possible and welcome but adding a URL to it is... non trivial. There's two reasons for that: the first one is that it's a piece of legacy code that's both platform-dependent and inflexible. Its rewrite is overdue but alas we haven't had the resources to do it yet. The second one stems from the context we're in: the browser crashed. Putting info in a URL that the user is supposed to visit is thus possible but not guaranteed to work if we hit a startup crash (and the user doesn't have another browser).
So as far as the browser crash reporter client is concerned I'm all for improving the wording but I'd rather not introduce URLs in it (though nothing prevents us from creating an easily discoverable page with more information and link it from the other crash reporter dialogs in the browser).
Just put a warning in red and bold text for now until a better solution is made.
"Crash dumps can contain urls, passwords, cookies and other sensitive information"
At least respect the user enough to get informed enthusiastic consent.
| Comment hidden (off-topic) |
|
|
||
Updated•9 months ago
|
|
||
Updated•27 days ago
|
Description
•