sessionstore.js stores contents of password fields in plaintext

VERIFIED FIXED in Firefox 3.1b1

Status

()

Firefox
Session Restore
--
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Michael Liddle, Assigned: Simon Bünzli)

Tracking

({privacy, verified1.8.1.18, verified1.9.0.4})

3.0 Branch
Firefox 3.1b1
privacy, verified1.8.1.18, verified1.9.0.4
Points:
---
Bug Flags:
blocking1.9.0.4 +
wanted1.9.0.x +
blocking1.8.1.18 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:want P2], URL)

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

If browser.sessionstore.privacy_level is set to either 1 (default) or 0 some extra page details, including form data, are stored in sessionstore.js. This _includes_ fields whose type is marked "password," and this is done in plaintext.

This occurs regardless of a user's "remember password" settings, whether they have a master password set or not, or whether they have form autofill turned on or not.

While I agree that for many cases this is good behaviour (e.g. for large forms), and that setting privacy level to 1 reduces the chance of highly secure passwords becoming stored, I believe that an exception should be made for password fields in _all_ cases. This is especially important in a world where users often have the same password for https and other, less secure, protocols.

I in fact came accross this problem using the Remote PwdHash form (https://www.pwdhash.com) saved to a USB stick, so that the URL had a file:// prefix, so privacy level set to 1 issued me no protection. This problem is a significant threat to such a strategy since it can leave a user's master password, in plaintext, on disk.

Reproducible: Always

Steps to Reproduce:
1. Navigate to a page with a password field, that is not https://
2. Enter "testpassword" into the password field
3. Execute `cd ~/.mozilla/firefox`
4. Execute `grep -R testpassword *`
5. Observe.
Actual Results:  
sessionstore.js contains the string "testpassword"

Expected Results:  
No copy of the password string should be found (at least not in relation to the one just entered in the password field)

A workaround is to set browser.sessionstore.privacy_level to 2, and prevent _any_ form data being stored from any page. However this loses the advantages (mentioned above) of such a feature.
(Removing the security flag since keeping this bug restricted isn't going to protect users.)
Component: Security → Session Restore
QA Contact: firefox → session.restore
OS: Linux → All
Hardware: PC → All
This is an excellent idea.
Group: core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.3?
Flags: blocking-firefox3.1?
Keywords: privacy
Whiteboard: [sg:want P2]

Comment 3

10 years ago
This should be fixed by bug 346337.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Depends on: 346337
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b1
Version: unspecified → 3.0 Branch
(Assignee)

Comment 4

10 years ago
Created attachment 338324 [details] [diff] [review]
one-line branch patch

Let's fix this on the branch as well, considering how little is missing.
Assignee: nobody → zeniko
Status: RESOLVED → REOPENED
Attachment #338324 - Flags: review?(dietrich)
Attachment #338324 - Flags: approval1.9.0.3?
Resolution: FIXED → ---
(Assignee)

Comment 5

10 years ago
Created attachment 338325 [details] [diff] [review]
regression test
[Checkin: Comment 10]

... and make sure that this doesn't regress on Trunk.
Attachment #338325 - Flags: review?(dietrich)
(Assignee)

Updated

10 years ago
Status: REOPENED → ASSIGNED
Flags: blocking-firefox3.1?

Comment 6

10 years ago
Still fixed on trunk, right? Use the fixed1.9.0.3 keyword for the branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
qawanted: does this affect Firefox 2.0.0.x as well?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x?
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.3+
Flags: blocking1.8.1.18?
Keywords: qawanted
(Assignee)

Comment 8

10 years ago
Comment on attachment 338324 [details] [diff] [review]
one-line branch patch

The same fix also applies to the 1.8.1 branch.
Attachment #338324 - Flags: approval1.8.1.18?
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18+
Keywords: qawanted
Whiteboard: [sg:want P2] → [sg:want P2] need r=dietrich
Attachment #338324 - Flags: review?(dietrich) → review+
Attachment #338325 - Flags: review?(dietrich) → review+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
Whiteboard: [sg:want P2] need r=dietrich → [sg:want P2][checkin-needed only for the regression test]
Comment on attachment 338324 [details] [diff] [review]
one-line branch patch

Approved for 1.8.1.18 and 1.9.0.4, a=dveditz for release-drivers

Please add the fixed1.8.1.18 and fixed1.9.0.4 keywords when you check in on the respective branches.
Attachment #338324 - Flags: approval1.9.0.4?
Attachment #338324 - Flags: approval1.9.0.4+
Attachment #338324 - Flags: approval1.8.1.18?
Attachment #338324 - Flags: approval1.8.1.18+
(Assignee)

Updated

10 years ago
Whiteboard: [sg:want P2][checkin-needed only for the regression test] → [sg:want P2][checkin-needed on Trunk (tests) and the 1.9.0 and 1.8.1 branches]
Comment on attachment 338325 [details] [diff] [review]
regression test
[Checkin: Comment 10]

http://hg.mozilla.org/mozilla-central/rev/9e89fa5f3959
Attachment #338325 - Attachment description: regression test → regression test [Checkin: Comment 10]
Whiteboard: [sg:want P2][checkin-needed on Trunk (tests) and the 1.9.0 and 1.8.1 branches] → [sg:want P2][checkin-needed on the 1.9.0 and 1.8.1 branches]
checked in on branch:

Checking in browser/components/sessionstore/src/nsSessionStore.js;
/cvsroot/mozilla/browser/components/sessionstore/src/nsSessionStore.js,v  <--  nsSessionStore.js
new revision: 1.101; previous revision: 1.100
done
Keywords: fixed1.9.0.4
Whiteboard: [sg:want P2][checkin-needed on the 1.9.0 and 1.8.1 branches] → [sg:want P2][checkin-needed on the 1.8.1 branches]
checked in on other branch:

Checking in browser/components/sessionstore/src/nsSessionStore.js;
/cvsroot/mozilla/browser/components/sessionstore/src/nsSessionStore.js,v  <--  nsSessionStore.js
new revision: 1.5.2.51; previous revision: 1.5.2.50
done
Keywords: checkin-needed → fixed1.8.1.18
Whiteboard: [sg:want P2][checkin-needed on the 1.8.1 branches] → [sg:want P2]
Created attachment 340367 [details] [diff] [review]
as checked in to 1.8.1 branch
I cannot reproduce this bug with Firefox 3.01 or 3.0.3 on Linux (Ubuntu). Note that the repro steps are slightly wrong in that you have to go into the profile directory. Sessionstore.js is not showing a testpassword value with either pwdhash.com or even my own blog's login (which has a password field and is not https).
(Assignee)

Comment 15

10 years ago
Can't test your blog's login (URL?), but e.g. the following URL displays the issue: http://www.w3schools.com/TAGS/tryit.asp?filename=tryhtml_inputpassword
This might be obvious, but to reproduce you need to enter text into the password field and leave it there (without submitting the form, etc.), and then wait until the session data is flushed to disk (could be up to 10 seconds IIRC).
(Assignee)

Comment 17

10 years ago
Instead of waiting and inspecting sessionstore.js, you can also close and reopen the tab or restart Firefox or duplicate the tab (through Ctrl+dragging) - the entered password should never be restored.
Yeah, I figured that one out, Gavin. Maybe I was hitting submit before. :-)

In any case, I can repro it clean now and it is fixed in 1.9.0.4. I checked with build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4pre) Gecko/2008102704 GranParadiso/3.0.4pre.
Keywords: fixed1.9.0.4 → verified1.9.0.4
Status: RESOLVED → VERIFIED
Verified for 1.8.1.18 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/2008102919 Firefox/2.0.0.18.
Keywords: fixed1.8.1.18 → verified1.8.1.18
You need to log in before you can comment on or make changes to this bug.