454908 - sessionstore.js stores contents of password fields in plaintext

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect)

Description

[Michael Liddle]

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.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

(Removing the security flag since keeping this bug restricted isn't going to protect users.)

Comment 2

[Daniel Veditz [:dveditz]]

This is an excellent idea.

Comment 3

[Dão Gottwald [:dao]]

This should be fixed by bug 346337.

Comment 4

[Simon Bünzli]

Attachment: one-line branch patch

Let's fix this on the branch as well, considering how little is missing.

Comment 5

[Simon Bünzli]

Attachment: regression test [Checkin: Comment 10]

... and make sure that this doesn't regress on Trunk.

Comment 6

[Dão Gottwald [:dao]]

Still fixed on trunk, right? Use the fixed1.9.0.3 keyword for the branch.

Comment 7

[Daniel Veditz [:dveditz]]

qawanted: does this affect Firefox 2.0.0.x as well?

Comment 8

[Simon Bünzli]

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

The same fix also applies to the 1.8.1 branch.

Comment 9

[Daniel Veditz [:dveditz]]

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.

Comment 10

[Serge Gautherie (:sgautherie)]

Comment on attachment 338325 [details] [diff] [review]
regression test
[Checkin: Comment 10]

http://hg.mozilla.org/mozilla-central/rev/9e89fa5f3959

Comment 11

[Dietrich Ayala (:dietrich)]

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

Comment 12

[Dietrich Ayala (:dietrich)]

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

Comment 13

[Dietrich Ayala (:dietrich)]

Attachment: as checked in to 1.8.1 branch

Comment 14

[Al Billings [:abillings - ex-MoCo]]

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).

Comment 15

[Simon Bünzli]

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

Comment 16

[:Gavin Sharp [email: [e-mail]]]

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).

Comment 17

[Simon Bünzli]

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.

Comment 18

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 19

[Al Billings [:abillings - ex-MoCo]]

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.