Closed Bug 678341 Opened 8 years ago Closed 8 years ago

Fennec profile data is accessible to all applications on the device when Fennec is moved to the SD card

Categories

(Firefox for Android Graveyard :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 721084
Firefox 8

People

(Reporter: briansmith, Unassigned)

References

Details

(Whiteboard: [sg:high])

This was caused by bug 615519. 

Normally on Android, when you move an app to the SD card, the app's data stays in the internal memory and the data remains inaccessible to other apps (unless debuggable == true, like Ian explained above). In other words, by default, the filesystem's per-app sandboxing remains intact.

However, when Fennec detects that it has been installed on the SD card, it moves all the data files to the SD card to, in a world-read/writable location. That is, Any application running on the device, or any device connected to the phone via USB, can read or write to any file in the user profile, including all the security configuration files, SSL trust database, SSL certificate trust override file, extension configuration (i.e. any application on the phone can install an extension into Firefox), places database, preferences, etc. (Note also that, AFAICT, some files in the profile can be used to force Firefox to load and later run binary libraries and/or JS code from arbitrary locations on disk.)

Until we can sort out what files are safe to store on the SD card, we should undo the change from bug 615519 ASAP and change Fennec to move profiles from the SD card back to the internal storage when it detects that the profiles are stored on the SD card.
Target Milestone: --- → Firefox 8
According to alexp, this has the same or worse effects as setting debuggable = true in the manifest, which is what we fixed in bug 658691.
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [sg:high]
I see from the comments in bug 615519 that this was a conscious tradeoff but when I discussed it with people on secteam today they agreed that this seems too dangerous.
Are we talking about keeping the whole profile in the internal memory or splitting it?

A user profile on one of my Android devices is 16MB, and it could be bigger. Personally I would not want to keep such a big profile in the limited internal memory, even knowing it will be at risk when moved to the SD card. Beltzner explained this pretty well in the bug 615519.
Some of the sensitive files in the profile are protected and/or MAC'd. These could be moved to the SD card. If there are other large databases in the profile that aren't encrypted/MAC'd, and we want to be able to store them in the user profile, then we need to file bugs to encrypt/MAC them.

If we want to move the entire profile over, then we need to come up with a way to encrypt/MAC the entire profile. Then many of the security issues will be resolved.

Other things, like preventing other applications from installing extensions silently, may have more nuanced aspects that I am not aware of yet, that might not be resolved simply by encrypting/MACing more data in the profile.
See Also: → 681003
Blocks: 681000
just a note that this is a result of the SD card using the FAT filesystem which has no concept of read/write permissions (everything is readable and writeable and this can;t be changed).
additionally Lucas and I took a look at other Android browsers (Dolphin, Opera, Sky Fire) when installed to the SD card and none of them stored any data to the SD card without explicit user action (choosing to backup data to the SD card or move bookmarks to SD card etc). I tried saving passwords, bookmarks, and loading pages with images that should be cached and by default, nothing was written to the SD card.
also applications need the Android permission WRITE_EXTERNAL_STORAGE to write to the SD card, strangely i didn't see a corresponding read permission..
Are we doing any further work on this issue? It hasn't been touched in six and a half months and isn't assigned to anyone.
Well there is bug 721084. Don't believe it to be a priority for the initial native release.
(In reply to Kevin Brosnan [:kbrosnan] from comment #9)
> Well there is bug 721084. Don't believe it to be a priority for the initial
> native release.

the other bug is unhidden - maybe we should unhide this one ? it's an sg:high though, unless people have other views on that ? it would be great to get this fixed before the release, i know the schedule is tight though..
Can we just make this bug dependent on bug 721084?

Of course, no one is assigned that bug either. 

With over six months of no one doing anything, it is hard to believe anyone feels pressure to fix this issue soon.
This bug can be opened up since bug 721084 already discloses the problems. And this bug can be dup'd against bug 721084 too.
(In reply to Brian Smith (:bsmith) from comment #12)
> This bug can be opened up since bug 721084 already discloses the problems.
> And this bug can be dup'd against bug 721084 too.

i agree this is a dupe of 721084, if this bug is marked a duplicate of that, then 721084 should be given [sg:high] (or whatever other rating there's consensus on).

Personally, I think this is [sg:high], and please see comment 6 about other mobile browsers here.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 721084
Group: core-security
You need to log in before you can comment on or make changes to this bug.