Closed Bug 1294438 (CVE-2016-9062) Opened 3 years ago Closed 3 years ago
Private browsing browser traces (android) in browser
.db and wal file
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Firefox for Android Steps to reproduce: I visited some sites (9gag.com, google.com, etc.) in inkognito mode on my Firefox client on Android (Ver. 48.0), 'grep'ed those domains from all files in "/data/data/org.mozilla.firefox/files/mozilla/****.default/" and got binary mathes in the files "browser.db" and "browser.db-wal". Although this requires root, still incognito mode should provide some protection, at least it shouldn't leave traces in persistant files. Actual results: root@A0001:/data/data/org.mozilla.firefox/files/mozilla/baro4nyl.default # grep 9gag* Binary file browser.db-wal matches root@A0001:/data/data/org.mozilla.firefox/files/mozilla/baro4nyl.default # Expected results: root@A0001:/data/data/org.mozilla.firefox/files/mozilla/baro4nyl.default # grep 9gag* root@A0001:/data/data/org.mozilla.firefox/files/mozilla/baro4nyl.default #
Sebastian, can you investigate/forward this? Thanks!
Component: Untriaged → General
Product: Firefox → Firefox for Android
Summary: Inkognito browser traces → Private browsing browser traces (android) in browser.db and wal file
Local attacker can also access other persisted data on operating system outside of Fx's control, hence unhiding and rating sec-low.
Is there anything going to happen here? I am pretty sure many people really want to be able to use Inkognito mode without having to be afraid of leaving a history of their activities.
@grisha: Can you investigate what we are actually storing and what's causing this?
tracking-fennec: --- → ?
Flags: needinfo?(s.kaspari) → needinfo?(gkruglov)
Priority: -- → P1
(In reply to Daniel D. from comment #0) > I visited some sites (9gag.com, google.com, etc.) in inkognito mode on my > Firefox client on Android (Ver. 48.0), 'grep'ed those domains from all files > in "/data/data/org.mozilla.firefox/files/mozilla/****.default/" and got > binary mathes in the files "browser.db" and "browser.db-wal". Although this > requires root, still incognito mode should provide some protection, at least > it shouldn't leave traces in persistant files. I take it you started off with a fresh profile? Otherwise, if you visited these pages prior, there will be matches. It's an obvious condition of course, but I just wanted to clarify. I'll take a look into this and report back.
Forgot to mention that, i did clear the apps data through settings as well as reinstalling the app, and made the grep-tests before and after only visiting those websites in Inkognito mode.
tracking-fennec: ? → 51+
I've tried this in the current nightly (51) and in the latest aurora (50.0a2) - two builds I could easily get a hold to run in an i386 emulator - and I can certainly reproduce this. Culprit seems to be the metadata table. After browsing in the private mode, I see entries for the visited URLs in there.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached patch is probably enough - however, I can't reproduce this at all anymore to ensure :/ As far as I can tell, this is the only place where we actually write into the metadata table, so just marking this as a no-op for the PrivateTab seems sufficient.
Comment on attachment 8787062 [details] Bug 1294438 - Do not store metadata for private tabs https://reviewboard.mozilla.org/r/75898/#review73914
Attachment #8787062 - Flags: review?(s.kaspari) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/4c0092cbaf25 Do not store metadata for private tabs r=sebastian
Should we uplift?
Sure, as soon as it lands on m-c I guess.
Let's definitely uplift this into Aurora, and perhaps Beta? Not sure if last week is too late for sec-low fixes to be uplifted. [Feature/regressing bug #]: private browsing [User impact if declined]: Opening private tabs sometimes persists metadata information about the tab, specifically page URL and an icon url. This information is stored, along with a timestamp, in browser.db->metadata table. If there's root access to the device, it might be possible to see some information about private tabs that were opened. Note that metadata is not always stored for a tab (I'm not quite sure what the required conditions are), so this bug doesn't always leak private browsing information - but it has the potential. [Describe test coverage new/current, TreeHerder]: Manual testing. [Risks and why]: Low to medium risk; private tab's method to store metadata was overridden to be a no-op. "Store metadata" action is triggered from within Gecko, and I don't have a full understanding of conditions under which it decides to store this information. From manual testing there isn't any visible impact though. [String/UUID change made/needed]: N/A
Comment on attachment 8787813 [details] [diff] [review] private-browsing.patch Too late for beta but happy to take it in 50
This is really more of a sec-moderate (on the lowish end). We should uplift to Aurora at least.
(In reply to Daniel Veditz [:dveditz] from comment #18) > This is really more of a sec-moderate (on the lowish end). We should uplift > to Aurora at least. It's already in aurora.
Hi, just so i know, will there be anything related to the hall of fame? Best regards, Daniel D.
If you have general questions, please write to firstname.lastname@example.org rather than commenting in bugs. Thanks.
You need to log in before you can comment on or make changes to this bug.