Closed Bug 822682 Opened 10 years ago Closed 10 years ago

Firefox freezes on smartcard re-insertion

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
18 Branch
Platform:
x86_64
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox18 + verified
firefox19 --- verified
b2g18 --- fixed

People

(Reporter: alvaro.rocha, Assigned: briansmith)

Details

(Keywords: hang, regression, Whiteboard: [qa-]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11

Steps to reproduce:

In general, when calling the initialisation function of a PKCS#11 library, the calling function indicates that it wants to perform multi-threaded access by using the CKF_OS_LOCKING flag and can propose synchronisation functions if desired. If the library is not able to guarantee multi-threaded operation, it can inform the calling function by returning the CKR_CANT_LOCK error.

We have a PKCS#11 library which does not support multi-threaded access, therefore it returns CKR_CANT_LOCK.
As such, and up until now, the behaviour of Firefox with regards to our library has been as follows:

--> Call to the C_Initialize function with the CLF_OS_LOCKING_OK flag and proposing its synchronisation functions.
<-- Response from the library: CKR_CANT_LOCK.

--> Call to the C_Initialize function, without flags and without synchronisation functions.
<-- Response from the library: CKR_OK.

However, since the beta version of Firefox 18 , this behaviour creates a deadlock within its own (Firefox's) threads during a card event that is preceded by an SSL authentication by client certificate.



Actual results:

Firefox 18 locks-up.


Expected results:

Firefox 18 shouldn't lock-up.
Severity: normal → blocker
Component: Untriaged → Security
OS: Windows 7 → All
Severity: blocker → critical
Status: UNCONFIRMED → NEW
tracking-firefox18: --- → ?
Component: Security → Security: PSM
Ever confirmed: true
Keywords: hang, regression
Product: Firefox → Core
(In reply to Alvaro from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML,
> like Gecko) Chrome/23.0.1271.97 Safari/537.11
> 
> Steps to reproduce:
> 
> In general, when calling the initialisation function of a PKCS#11 library,
> the calling function indicates that it wants to perform multi-threaded
> access by using the CKF_OS_LOCKING flag and can propose synchronisation
> functions if desired. If the library is not able to guarantee multi-threaded
> operation, it can inform the calling function by returning the CKR_CANT_LOCK
> error.
> 
> We have a PKCS#11 library which does not support multi-threaded access,
> therefore it returns CKR_CANT_LOCK.
> As such, and up until now, the behaviour of Firefox with regards to our
> library has been as follows:
> 
> --> Call to the C_Initialize function with the CLF_OS_LOCKING_OK flag and
> proposing its synchronisation functions.
> <-- Response from the library: CKR_CANT_LOCK.
> 
> --> Call to the C_Initialize function, without flags and without
> synchronisation functions.
> <-- Response from the library: CKR_OK.
> 
> However, since the beta version of Firefox 18 , this behaviour creates a
> deadlock within its own (Firefox's) threads during a card event that is
> preceded by an SSL authentication by client certificate.
> 
> 
> 
> Actual results:
> 
> Firefox 18 locks-up.
> 
> 
> Expected results:
> 
> Firefox 18 shouldn't lock-up.

Hi Alvaro - the only way this has a chance of getting fixed for FF18 is if you help with a regression range (we don't have access to the affected hardware).

Can you follow the instructions at http://harthur.github.com/mozregression/ and copy/paste the output which explains the last known good and first known bad build?
Hi Alex, 

I have followed your instructions and this is the output from the exercise:

Last good nightly: 2012-10-01
First bad nightly: 2012-10-02

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-10-01&enddate=2012-10-02

Hope this helps, please keep me updated on any progress or news and let me know if I can assist further.


Best regards,

Alvaro
Looks like the NSS upgrade
This sounds a lot like bug 357025: "NSS 3.14 added support for tokens that make use of CKA_ALWAYS_AUTHENTICATE. However, when authenticating with such tokens, it was possible for an internal lock to be acquired twice, causing a hang. This hang has been fixed in NSS 3.14.1."

- https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.1_release_notes

We can update to NSS 3.14.1 for Firefox 18 to fix this problem, if we do so right away.
(In reply to Alvaro from comment #2)
> Hi Alex, 
> 
> I have followed your instructions and this is the output from the exercise:
> 
> Last good nightly: 2012-10-01
> First bad nightly: 2012-10-02
> 
> Pushlog:
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2012-10-
> 01&enddate=2012-10-02

Thanks, this is very useful. Could you please try from a very recent nightly? We upgraded to NSS 3.14.1 on Nightly a couple of weeks ago. If you can verify that nightly is working correctly then we may be able to fix this in time for Firefox 18.
(In reply to Brian Smith (:bsmith) from comment #4)
> This sounds a lot like bug 357025: "NSS 3.14 added support for tokens that
> make use of CKA_ALWAYS_AUTHENTICATE. However, when authenticating with such
> tokens, it was possible for an internal lock to be acquired twice, causing a
> hang. This hang has been fixed in NSS 3.14.1."
> 
> - https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.1_release_notes
> 
> We can update to NSS 3.14.1 for Firefox 18 to fix this problem, if we do so
> right away.

Let's do this on Aurora now, and discuss whether it makes sense to do the same for FF18 prior to our final beta (going to build 12/26). What's the risk profile on that uplift overall? I'm leaning towards suggesting that impacted enterprise users use the unaffected ESR17, at least for a cycle.
Hi,
Our company is a french government agency in charge of the management of information systems for health care professionals. 
We provide several Web Portals for our users like these ones : https://ledmp.dmp.gouv.fr/ and https://espacepro.ameli.fr/.
These portals require a client/server mutual authentication through the usage of a smart card on the client side.
A very important part of our users are not enterprise users (private doctors for example) and we will have serious troubles due to this issue on FF18 if the fix is not applied to the release version.
Hi,

Good news, i've tested the last Nighty, v20.0a1 (2012.12.23), and the problem has disappeared !
Good news indeed, may we have a status about the upgrade to NSS 3.14.1 for the final beta of FF18 ?

Thanks in advance.
(In reply to Brian Smith (:bsmith) from comment #10)
> https://hg.mozilla.org/releases/mozilla-aurora/rev/4cb9aa663062

Hi,

Does it mean that we will have to wait FF19 before getting a fix ?

We currently have no solution for our users on FF18 (except using an other browser at least temporarily). It means that we will have a lot of calls to our hotline as soon as FF18 is released and we have to get prepared for this.
(In reply to Alvaro from comment #8)
> Hi,
> 
> Good news, i've tested the last Nighty, v20.0a1 (2012.12.23), and the
> problem has disappeared !

Thanks for testing this!

(In reply to david.decroix from comment #11)
> Does it mean that we will have to wait FF19 before getting a fix ?
> 
> We currently have no solution for our users on FF18 (except using an other
> browser at least temporarily). It means that we will have a lot of calls to
> our hotline as soon as FF18 is released and we have to get prepared for this.

We're trying to find the best way to resolve the issue in Firefox 18. I think we will probably have a solution for Firefox 18 but it isn't guaranteed yet.

It would help us a lot if you could download and test Firefox Nightly from http://nightly.mozilla.org/ to make sure that the problem is fixed on *your* systems too.
(In reply to david.decroix from comment #11)
> (In reply to Brian Smith (:bsmith) from comment #10)
> > https://hg.mozilla.org/releases/mozilla-aurora/rev/4cb9aa663062

I forgot to clean up security/patches when I pushed NSS 3.14.1 to mozilla-aurora. This commit does that:
https://hg.mozilla.org/releases/mozilla-aurora/rev/5bc5fbb72f33

I uplifted both sets of changes to mozilla-beta in one commit:
https://hg.mozilla.org/releases/mozilla-beta/rev/c59af840586d

If this uplift causes problems, then just backout changeset c59af840586d. (Note: I will probably not be available before Monday to help with the backout.)

David, this change for Firefox 18 will not be effective until we build a new Firefox 18 beta. It is still very important that we get your feedback on how well Firefox Nightly works before then, so we can decide whether to keep the upgraded NSS 3.14.1 or undo this commit. Thanks for your help!
(In reply to Brian Smith (:bsmith) from comment #13)
> I uplifted both sets of changes to mozilla-beta in one commit:
> https://hg.mozilla.org/releases/mozilla-beta/rev/c59af840586d

That was GECKO180_2012122710_RELBRANCH.

This is now landed on the default branch too:
https://hg.mozilla.org/releases/mozilla-beta/rev/4af665f1dff4
(In reply to Brian Smith (:bsmith) from comment #12)
> It would help us a lot if you could download and test Firefox Nightly from
> http://nightly.mozilla.org/ to make sure that the problem is fixed on *your*
> systems too.

Sorry for the late answer, it has been tested with the Nightly version and its working fine.

We are now waiting for FF18 Beta 6 to check the good result. I will keep you informed as soon as it is tested.

Thanks a lot for your efforts.
Hi Brian,

Here is my last results with the lastest builds (2012-12-27) :

FF 18 beta6   : KO
FF 19 aurora) : OK
FF 20 central : OK
Same results here with the latest versions retrieved on https://ftp.mozilla.org/pub/mozilla.org/firefox/

(In reply to Brian Smith (:bsmith) from comment #13)
> David, this change for Firefox 18 will not be effective until we build a new
> Firefox 18 beta. 

Will there be another build for Firefox 18 beta ?
In addition to my previous comment, the NSS version is still 3.14 (3.14.0.1) for the current FF 18 beta 6 (build 1) whereas it has already been updated to 3.14.1 (3.14.1.0) for Aurora.

(NSS library version available through the "Help/Troubleshooting Information" menu)
FF18 beta 6 posted on http://www.mozilla.org/fr/firefox/beta/ now gives me the same results for Alvaro.
- 18 FF beta6: KO 
  => MD5: 234D5ABE91E854A74E1562A3FDD4D373

The version of NSS included in FF6beta6 always 3.14.0.1 and not 3.14.1.0 as in the aurora that works OK.

Will there be another build for Firefox 18 beta ?
You can try with the debug builds from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012-12-28-mozilla-beta-debug/ which were built _after_ brian's pushes.
And for the record, 18.0b6 was built before the fixes, see the tags on http://hg.mozilla.org/releases/mozilla-beta/shortlog/117603
(In reply to laurent.jouanneau from comment #20)
> Will there be another build for Firefox 18 beta ?

As far as I know, another one is planned that should hopefully fix this bug and another issue that was recently found.
We do have a plan to get another beta(18.0b7) out early next week to address this issue.I will get back to you with more details once we have gone-to build with that beta on its release date.
Thank you for this proposal.
We are looking forward to testing this next beta 7 (18.0b7).
The release will be distributed anyway January 6, 2013?
(In reply to bhavana bajaj [:bajaj] from comment #24)
> We do have a plan to get another beta(18.0b7) out early next week to address
> this issue.I will get back to you with more details once we have gone-to
> build with that beta on its release date.

Thanks for the good news and to keep us informed, on our side we will be available for testing as soon as FF 18.0b7 is available.
Hi
Firefox  18.b07 available on  https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0b7/win32/fr/ has been tested on our side : it's working fine now.
Thanks David. Can you also check if the latest Firefox 19.0a2 Aurora build is fixed?

Alvaro, can you also confirm this is working for you now with 18.0b7 and 19.0a2?

Pre-emptively marking resolved fixed based on comment 27. Unfortunately, QA does not have the facility to test with smartcards so I'm tagging this [qa-]. We'll depend on David and Alvaro's help in verifying the fix.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [qa-]
Hi
I confirm the fix on these versions (18.0b7 & 19.0a2)
Thanks a lot
Marking this verified fixed based on comment 29 and 27. Thank you for the help!
Status: RESOLVED → VERIFIED
status-firefox18: fixed → verified
status-firefox19: fixed → verified
You need to log in before you can comment on or make changes to this bug.