1331238 - Firefox cookies sqlite db stored unencrypted on macOS

Status: RESOLVED DUPLICATE of bug 56788

(Firefox :: Untriaged, defect)

Description

[Mohamed A. Baset]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce:

OS: macOS Sierra 10.12.2
Firefox version: 50.1 (latest update)

A security problem related to Firefox cookies sqlite database which is stored unencrypted and not immune against any external service/malware accessing.

As a test the database resides here: $HOME/Library/Application Support/Firefox/Profiles/ could be grabbed with this bash script PoC:


#!/bin/bash
# Simple Browsers Cookies Grabber by @Seekurity
mkdir ~/Desktop/Cookies/
# Grab Firefox Cookies
# Searches for the default profile name
path=$(find "$HOME/Library/Application Support/Firefox/Profiles/" -maxdepth 1 -type d -name '*default*' -print0)
file="$path/cookies.sqlite"
cp "$file" ~/Desktop/Cookies/FirefoxCookies.db

and could be used for a later use by extracting all the valuable user's sessions and other data.

Also i managed to read the database by any .sqlite db management apps eg."DB Browser for SQLite" without any effort to decrypt or even doing anything.


Actual results:

Firefox cookies sqlite database is readable by any (script, sqlite db viewer or even an unexpected malware)


Expected results:

Cookies sqlite database must be encrypted on macOS with the current user's keychain credentials and non readable by other applications.

Comment 1

[:Gijs (he/him)]

This is well-known, so it doesn't need to stay hidden. It's an old decision. You haven't presented any reasons to revisit it. We're doing the same as other browsers.

If you don't trust applications with read access to arbitrary (user-readable) parts of your disk, don't run them.

Comment 2

[Mohamed A. Baset]

"We're doing the same as other browsers."

Have you took a look on how Google Chrome is encrypting its sqlite database on macOS?

Comment 3

[Matthew N. [:MattN]]

To save Gijs some time, see bug 1163166.

I think the best way to get bug 116916 revisited would be to send an email to the security mailing list: https://www.mozilla.org/en-US/about/forums/#dev-security 

In your message you should explain how encrypting the cookies would actually stop malware running on the system from getting access to a user's accounts. On Windows I don't believe it will stop an attacker since there are keyloggers that can run as the user and don't require administrator privileges. Perhaps that's not possible on OS X.

Comment 4

[:Gijs (he/him)]

(In reply to Mohamed A. Baset from comment #2)
> "We're doing the same as other browsers."
> 
> Have you took a look on how Google Chrome

I did, actually.

> is encrypting its sqlite database
> on macOS?

It doesn't. The sqlite db is not encrypted as a whole. On my machine, many of the sqlite values are in plaintext, though it seems if I scroll down (which I didn't bother doing yesterday), some values are encrypted as Matt noted in comment #3. Some, but not all.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #3)
> I think the best way to get bug 116916 revisited would be to send an email
> to the security mailing list:
> https://www.mozilla.org/en-US/about/forums/#dev-security 

Emailing the security mailing list is a good idea.

FWIW, especially if this will prompt for keychain passwords I don't really think we should be revisiting this - as bug 116916 already noted, prompting isn't likely a usable experience for most users.

If we don't need to prompt for keychain passwords, then I'm not clear on what is gained, because presumably malware could obtain the same values without prompting. Plus there are webextension APIs to read cookies, so malware could just install a webextension to read those cookies... It's not clear how Chrome does this because the link in bug 1163166 is dead.

Note that if we wanted to do this for the cookies DB we would need to use the same system for the sessionstore file.

> In your message you should explain how encrypting the cookies would actually
> stop malware running on the system from getting access to a user's accounts.
> On Windows I don't believe it will stop an attacker since there are
> keyloggers that can run as the user and don't require administrator
> privileges. Perhaps that's not possible on OS X.

Comment 5

[:Gijs (he/him)]

(In reply to :Gijs from comment #4)
> (In reply to Mohamed A. Baset from comment #2)
> > "We're doing the same as other browsers."
> > 
> > Have you took a look on how Google Chrome
> 
> I did, actually.
> 
> > is encrypting its sqlite database
> > on macOS?
> 
> It doesn't. The sqlite db is not encrypted as a whole. 

To be clear, the distinction here matters because, once your threat model includes malware that gets installed locally, the names and domains are valuable for malware agents in and of themselves (they basically provide rudimentary history by domain), and would be required for the permission sets to read them if you were to, say, want to install a temporary webextension to read those cookies.