147924 - javascript variables contain remembered password

Status: RESOLVED WORKSFORME

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Jan Moesen]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+)
Gecko/20020529
BuildID:    2002052908

I use a bookmarklet to tell the length of any string I input:

javascript:var s = prompt("Input the string to measure the length of:"); if (s)
alert("The length of \n\n\t\"" + s + "\"\n\nis " + s.length + " chars.");

For no apparent reason, mozilla SKIPS the prompt(), and automatically fills the
variable s with one of my remembered passwords. I tried renaming the variable to
f: no luck; to fg (maybe it was a one-letter thing): no luck. Seems to me this
is a security issue. Wouldn't know about earlier versions, although it has never
happened to me before. I installed RC3 a few minutes ago.



Reproducible: Always
Steps to Reproduce:
1. make a bookmarklet for the javascript: URL from above
2. restart your browser (unclear, but seems the bug goes away after a while)
3. click the bookmarklet (or paste the javascript: URL from above in the
location bar)



Actual Results:  This -over here, RC3 2002052908 XP- skips the prompt and tells
me the length of "my1337passw0rdhere" is X chars.

Expected Results:  I wanted to know what the length of "my penis" was, but I
couldn't get the darn prompt to show up.

Comment 1

[Jan Moesen]

From Handling Mozilla Security Bugs
(http://www.mozilla.org/projects/security/security-bugs-policy.html)

* Security bug reports can be treated as special and handled differently than
"normal" bugs. In particular, the mozilla.org Bugzilla system will allow bug
reports related to security vulnerabilities to be marked as
"Security-Sensitive," and will have special access control features specifically
for use with such bug reports. However a security bug can revert back to being a
normal bug (by having the "Security-Sensitive" flag removed), in which case the
access control restrictions will no longer be in effect.


WHERE can I set that flag then?

Comment 2

[Stephen P. Morse]

You can't set it, but I can and I just did.

Comment 3

[georgi - hopefully not receiving bugspam]

I can't reproduce this with trunk build on linux.
Only tried with pasting in the location bar - if the user has untrusted
bookmarklets it is user's responsibility IMHO.

Comment 4

[Jan Moesen]

Can't reproduce on my PC at school using W2K
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020529

When I get home, I'll check the password manager to see what the index of that
password is.

>if the user has untrusted bookmarklets it is user's responsibility IMHO.
If I were to execute the same code from a webpage, would it still be the user's
responsibility?

Comment 5

[georgi - hopefully not receiving bugspam]

>If I were to execute the same code from a webpage, would it still be the user's
responsibility?

No, web page is different. Can you give example from web page?

Comment 6

[Jan Moesen]

Attachment: here's an example of what happened - password scrambled, of course

attached a screenshot of what *happened* (past time)

feel free to close this bug
hasn't happened to me since I upgraded to the 1.0 release (2002053012)

if anyone wants to know: the password was the password associated with the
first entry in the password manager list

Comment 7

[Keyser Sose]

I am going to mark this WFM please notify us immediately if this occurs again.

Comment 8

[Jan Moesen]

A friend of mine has had this happen too, again with a bookmarklet that worked
fine in one version 
   (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130)
but showed a remembered password and no prompt in another
   (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207
    Phoenix/0.5)

We did a few tests, by typing a script into the URL bar, as well as by opening
an HTML document. It appears that prompt() immediately and quite bizarrely
returns a remembered password instead of prompting for input.

The minimal test case is:
   javascript:alert(prompt());

I'll attach an HTML document and a screenshot showing this behaviour. Really
weird, and 100% reproducible _in the same profile with the same version_.
Installing the latest Phoenix nightly fixed the problem, without creating a new
profile.

I looked for the function definition of the JavaScript prompt() in lxr, but
didn't really get anywhere. A quick tip on where it's at would be nice. ;-)

Comment 9

[Jan Moesen]

Attachment: a sample HTML document that triggers the bug in vulnerable browsers

Comment 10

[Jan Moesen]

Attachment: Screenshot of sample output, albeit scrambled

Rather useless, OK, but I had to give *some* proof, right?

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Does 1.3b or really recent trunk builds have this problem? The easiest way to
get the latest build is by going to http://www.mozillazine.org/ and downloading
the latest nightly (links at the top).

Comment 12

[Jan Moesen]

That's the whole problem, it's not easily reproducible. It just *happens*. The
latest Phoenix nightly he just installed doesn't exhibit this behaviour, but
that might not have all that much to do with it. After all, I had my problem
with 1.0 beta, fixed by installing 1.0 final. However, he had it with 1.3b,
which came long after 1.0 final, right? Or were they branched and then remerged,
and all that?

I'm really sorry for such a vague bug, and realize it would be more important if
there was a 1-2-3 way to get the effect. No dice, though.

Comment 13

[Mitchell Stoltz (not reading bugmail)]

I assume the password manager was causing this, somehow. Or maybe session
history. Jan, was it a password you had used during the same browsing session,
in the same window?

Comment 14

[georgi - hopefully not receiving bugspam]

This seems very similar to bug 148520
window.prompt is returning a saved password instead of prompting

Comment 15

[Jan Moesen]

Re: comment #14
Indeed it looks like it is the same bug. However, that was resolved fixed in
June, while my friend's build was from 20021207.

Re: comment #13
No, it was not a password I used a lot, and I don't recall having to have used
it before the bug 'worked'. Also, the mysterious friend of mine who had this
problem two days ago, says he hadn't used the password in weeks.

Comment 16

[Mitchell Stoltz (not reading bugmail)]

That rules out session history. But it was a password that you had stored in
Password Manager, right?

Comment 17

[Jan Moesen]

Yes, it was stored in the Password Manager. Can't remember if it was the first
or the last password stored, or no password in particular. Where is the code for
the prompt() implementation?

Comment 18

[Daniel Veditz [:dveditz]]

In bug 148520 the password it grabbed was the first one in the password
manager's list which is sorted alphabetically. Depending on the user it might be
an important password or an old unused one.

Darin: could this be a regression based on your revisions 1.231 and 1.232 in
signsign.cpp? si_GetURL() can return the first item in the list (bogus, as you
commented) if it's passed a null. That was 12/5 and 12/12, around the time this
was re-raised as an issue.

I can't reproduce though. Hope we can get more specific steps. Reopening while
we investigate this.

Comment 19

[Kai Lahmann (is there, where MNG is)]

Reporter: Can you reproduce this bug with a recent build of Mozilla (for
example, 1.4 RC1)? If so, then please comment again with details. If not, then
please resolve this bug as WORKSFORME. Thanks.

Comment 20

[Jan Moesen]

No, I haven't seen this since the last report. Should it happen again, I'll be
sure to notify you again. WFM.