Closed Bug 454908 Opened 13 years ago Closed 13 years ago

sessionstore.js stores contents of password fields in plaintext

Categories

(Firefox :: Session Restore, defect)

3.0 Branch
defect
Not set
major

Tracking

()

VERIFIED FIXED
Firefox 3.1b1

People

(Reporter: michael, Assigned: zeniko)

References

()

Details

(Keywords: privacy, verified1.8.1.18, verified1.9.0.4, Whiteboard: [sg:want P2])

Attachments

(3 files)

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]
This should be fixed by bug 346337.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 346337
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b1
Version: unspecified → 3.0 Branch
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 → ---
... and make sure that this doesn't regress on Trunk.
Attachment #338325 - Flags: review?(dietrich)
Status: REOPENED → ASSIGNED
Flags: blocking-firefox3.1?
Still fixed on trunk, right? Use the fixed1.9.0.3 keyword for the branch.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago13 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
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+
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+
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
Whiteboard: [sg:want P2][checkin-needed on the 1.8.1 branches] → [sg:want P2]
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).
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).
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.
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.
You need to log in before you can comment on or make changes to this bug.