If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

crypto.signText() will sign text when user enters a blank password




Security: PSM
8 years ago
3 years ago


(Reporter: Graham Leggett, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:needinfo], URL)


(1 attachment)



8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20090824 Firefox/3.5.3 GTB5
Build Identifier: Intel Mac OS X 10.4; en-US; rv: Gecko/20090824 Firefox/3.5.3

Normally, crypto.signText() presents the user with a dialog box, inviting them to choose a certificate to sign the text.

The signing happens when the end user enters their private key passphrase to confirm they actually want to sign the text. An incorrect passphrase will cause FF to refuse to sign the text.

A bug has been introduced into the FF UI, where the sense of the passphrase has been turned around.

What should happen is this:

- User enters correct passphrase: success
- User enters incorrect passphrase: reject
- User enters _blank_ passphrase: reject

What actually happens is this:

- User enters correct passphrase: reject (wrong)
- User enters incorrect passphrase: reject (correct)
- User enters _blank_ passphrase: success (wrong!!!)

As a result, if an unathorised user gains access to the browser, they are able to sign declarations using someone else's key, without having to enter a passphrase: security hole.

Reproducible: Always

Steps to Reproduce:
Assignee: nobody → kaie
Component: General → Security: PSM
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → psm
Hardware: x86 → All
I can't reproduce, do you have a sample page that demonstrates the problem?

Using something braindead like 
  javascript:alert(crypto.signText("random text to sign","ask"))
I don't see the problem.

If I enter garbage or blank I am reprompted, and if I enter my correct Master Password I get a signed chunk in the alert. If I cancel I get the string "error:userCancel"
Whiteboard: [sg:needinfo]
I'm also using a Mac OS 10.5 like you, but on the current Firefox 3.5.5

I can't think of any crypto-related changes that went into 3.5.4 and certainly not 3.5.5
oh, we did upgrade the crypto library (NSS) from 3.12.3 to 3.12.4 but I can't imagine that would have affected this. Let me go try 3.5.3
Yup, same experience with 3.5.3 in a new profile where I newly imported my certs. Seems to work fine.

Comment 5

8 years ago
Just checked again with FF v3.5.6, and the problem seems to still exist.

If you can send a PGP key, I can send details of how to access a test version of the system that shows the bug. Any valid cert recognised by crypto.signtext seems to show the problem. Any passphrase used (correct or otherwise) is rejected, a blank passphrase is accepted.

Comment 6

8 years ago
Created attachment 420706 [details]
Html page showing the problem

The following page from the application shows the problem.

Comment 7

8 years ago
Load the html file, and click on "request". crypto.signtext() will ask you to sign a declaration.

If you enter a wrong passphrase, crypto.sygntext will show you the window again (correctly). If you enter the correct passphrase, crypto.signtext will show you the window again (incorrectly). If you enter a *blank* passphrase (just press enter), the text will be signed and submitted back to the server, incorrectly.

Comment 8

8 years ago
Seamonkey below is now doing this as well, blowing our workaround out the water:

Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100105 SeaMonkey/2.0.2

Comment 9

7 years ago
Has anyone had the opportunity to take a look at the test case I provided?

Comment 10

7 years ago
I'm trying your html file, I click on "request". The "sign text" dialog shows up. 

I click "OK", the dialog closes, and immediately opens up again.

I enter "abc" (incorrect password", click "OK", the dialog closes, and immediately opens up again.

Can't reproduce your bug.

Comment 11

7 years ago
Graham, what behaviour do you see on the minimal test page at http://kuix.de/misc/test41/ ?

Comment 12

7 years ago
On the test page at http://kuix.de/misc/test41/, I am challenged to sign the sample text.

First, I try with a bogus passphrase, and am presented with the alert asking me for my passphrase again.

Next, I try it with the valid passphrase, and am presented with the alert asking me for my passphrase again.

Finally, I leave the passphrase blank, and the the text is signed, and I get a big alert box with what looks like the base64 signed text.

In other words, on my system I am able to reproduce the bug on your test page with the following version of FF:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100401 Firefox/3.6.3

Comment 13

7 years ago
Are you sure you are not confusing your "bogus" and your "valid" passphrase?
It sounds like!

Please try this:
- quit firefox
- start firefox
- go to prefs/advanced/encryption/security devices
- click software security device
- click login
- enter the passphrase that you assume is the "valid" one,
  the one that you entered and produced the signed text.

I suspect login will fail, and you will be asked to enter it again.

If you try with the "bogus" passphrase, I suspect you will login successfully.

Please use this mechanism to test login carefully.

I really think you will notice that you have mixed up the passphrases.

Am I right or wrong?

Comment 14

7 years ago
You're misunderstanding the bug.

The real problem is that a *blank* passphrase is accepted as a valid passphrase, allowing the text to be signed without the passphrase being provided.

The bogus passphrase is rejected (correctly), the real passphrase is also rejected (incorrectly), and the blank passphrase is accepted (incorrectly).

The problem was uncovered at an insurance company that uses crypto.signText to digitally sign claim approvals, a system that's worked fine since roughly 2003. After a FF update a while back, it was noticed that suddenly their passphrases stopped working. By accident, we discovered that a blank passphrase was accepted. We switched everyone from FF to Seamonkey, but shortly afterwards, that stopped working too.

Trying the software security device above, I see a "log in" and a "log out" button, but both buttons are greyed out.

Comment 15

7 years ago
Now I'm testing on a Mac OSX 10.5.8, Firefox 3.6.3

This isn't a development machine, so I'm sure I have an environment comparable with that of end users.

I created a new separate profile.
I enrolled for a test drive certificate from Verisign, and installed it.
I went to http://kuix.de/misc/test41/
I was prompted.
I did NOT enter as passphrase, but simply clicked OK.
Yes, in this scenario I get success, of course, because I have not set a master password.

So, I go ahead, go to preferences, and check "use a master password".
I use "abc", and get the confirmation, a master password was set successfully.

Again, I go to http://kuix.de/misc/test41/
I don't enter a password, but click OK.

As expected, the dialog comes up again, tried multiple times.

Next I enter the bogus passphrase "def". Same result. 
Dialog comes up again, no signature created.

Now I enter the correct "abc", and the signature gets created.

I quit Firefox and start it up again.
I go to prefs, advanced, encryption, devices, I click on "software security device", thereby "selecting it". This causes the "log in" button to switch from "gray" to "usable". I click it. I enter the bogus "def", and I'm prompted again. I enter the correct "abc" and the prompt disappears. The "log in" button changed to "gray", and the "log out" button changed to "usable". The "status" text, on top of the middle area says "logged" in.

Comment 16

7 years ago
(In reply to comment #14)
> Trying the software security device above, I see a "log in" and a "log out"
> button, but both buttons are greyed out.

Are you sure you clicked on software security device in order to select it?

Comment 17

7 years ago
(In reply to comment #14)
> You're misunderstanding the bug.

I understand your bug report, but I'm unable to reproduce it!

I get the opposite behaviour of yours. I have no idea why.

Comment 18

7 years ago
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
Close this almost three years later as incomplete.
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
Group: core-security
You need to log in before you can comment on or make changes to this bug.