User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:22.214.171.124) Gecko/20090824 Firefox/3.5.3 GTB5 Build Identifier: Intel Mac OS X 10.4; en-US; rv:126.96.36.199) 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: xxx
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.
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.
Created attachment 420706 [details] Html page showing the problem The following page from the application shows the problem.
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.
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:188.8.131.52) Gecko/20100105 SeaMonkey/2.0.2
Has anyone had the opportunity to take a look at the test case I provided?
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.
Graham, what behaviour do you see on the minimal test page at http://kuix.de/misc/test41/ ?
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:184.108.40.206) Gecko/20100401 Firefox/3.6.3
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?
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.
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.
(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?
(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.
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody
Close this almost three years later as incomplete.