Closed Bug 1863135 Opened 8 months ago Closed 6 months ago

Firefox can't be reopened after using FIDO2 USB authentication

Categories

(Core :: DOM: Web Authentication, defect, P2)

Product:
Core
Component:
DOM: Web Authentication
Version:
Firefox 118
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
121 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 121+
firefox121 --- verified
firefox122 --- verified
firefox123 --- verified

People

(Reporter: guillermox7, Assigned: jschanck)

References

Details

(Keywords: perf-alert)

Attachments

(3 files)

Bug 1863135 - reset webauthn service after transaction completion. r=keeler
48 bytes, text/x-phabricator-request
Details | Review
Process not closing immediately Fx121 RC
3.29 MB, image/gif
Details
Bug 1863135 - part 2: reset USB token manager even when there is no pending transaction. r=keeler
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-beta+
RyanVM
: approval-mozilla-release+
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

  1. Build and run https://github.com/psanford/tpm-fido, which acts as a USB FIDO2 token that allows you to log in via WebAuthn using your TPM to store keys.
  2. Go to WebAuthn.io
  3. Register with any username
  4. Close Firefox
  5. Try to reopen it

Actual results:

Firefox won't reopen or respond until it is killed using the system task manager

Environment:
System:
Kernel: 6.2.0-36-generic x86_64 bits: 64 compiler: N/A Desktop: Cinnamon 5.8.4 tk: GTK 3.24.33
wm: muffin dm: LightDM Distro: Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy
Machine:
Type: ThinkPad T14 Gen 2i
CPU:
Info: Intel Core i7-1165G7

Expected results:

Firefox should reopen

Please note the bug occurs from Firefox 118 onwards, even 120 (I've tested all versions published to Flathub and also downloaded binaries from Mozilla official page). I've reported the issue using Firefox 117 because I'm sticking to the last version that works.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Web Authentication' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Web Authentication
Product: Firefox → Core

Could you start Firefox with RUST_LOG=authenticator=debug and repeat the test? It seems like something from the authenticator-code is keeping Firefox alive, when you try to close it. Maybe we can see in the logs what.

Flags: needinfo?(guillermox7)

I have tried with my current version (117.0.1) and with all upwards versions (from 118.0.0 until 119.0.1). These are the results:

Firefox 119.0.1 with RUST_LOG=authenticator=debug (BUG IS REPRODUCED)

(Just after clicking on the 'Register' button in webauthn.io)

[INFO authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw2")): Permission denied (os error 13)
[INFO authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw0")): Permission denied (os error 13)
[INFO authenticator::transport::platform::device] new device "/dev/hidraw1"
[INFO authenticator::statemachine] Device "/dev/hidraw1" continues with the register process

(The TPM-FIDO screen asking for confirmation is shown in parallel)

  • If I click confirm from TPM-FIDO side, webauthn.io says I've successfully registered, but nothing else will appear in the logs. If I close Firefox at this moment, the process just stays alive until a timeout kills it (I guess 30s?)
  • If I click cancel from TPM-FIDO side, webauthn.io will say I denied the permission ("The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission."), and Firefox will output this to the log:

[WARN authenticator::ctap2] error happened: Error: Unexpected apdu status: WrongData

  • If I click confirm from TPM-FIDO side, but I don't close Firefox and instead I click Log in button in webauthn.io:

[INFO authenticator::statemachine] Statemachine was cancelled. Cancelling transaction now.
[INFO authenticator::transport::platform::transaction] Transaction was cancelled.
[INFO authenticator::transport::platform::device] new device "/dev/hidraw1"
[INFO authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw2")): Permission denied (os error 13)
[INFO authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw0")): Permission denied (os error 13)
[INFO authenticator::statemachine] Device "/dev/hidraw1" continues with the signing process

Firefox 117.0.1 with RUST_LOG=authenticator=debug (BUG IS NOT REPRODUCED)

(Just after clicking on the 'Register' button in webauthn.io)

[INFO authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw2")): Permission denied (os error 13)
[INFO authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw0")): Permission denied (os error 13)
[INFO authenticator::transport::platform::device] new device "/dev/hidraw1"
[INFO authenticator::statemachine] Device "/dev/hidraw1" continues with the register process

(The TPM-FIDO screen asking for confirmation is shown in parallel)

  • No matter if I confirm or cancel the registration process from TPM-FIDO side, this will be output to the log and I'm free to close
    Firefox at any point after this

[INFO authenticator::statemachine] Statemachine was cancelled. Cancelling transaction now.
[INFO authenticator::transport::platform::transaction] Transaction was cancelled.

Looks like what keeps Firefox 119 from closing is the registration transaction staying alive even after it finished from the UI perspective. For some reason, in Firefox 117 the transaction appears as cancelled as soon as I do anything from TPM-FIDO, but it actually works from webauthn.io side.

I thought this could be a bug on TPM-FIDO, but it's strange because the latest version of Chromium also works fine. Btw, hidraw0 and hidraw2 are my USB devices, and hidraw1 is tpm-fido.

Flags: needinfo?(guillermox7)

authenticator-rs keeps its device monitor thread alive after a transaction has
completed. This is a workaround to ensure that the device monitor thread does
not prevent the browser from closing.

Assignee: nobody → jschanck
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
See Also: → 1864526
Pushed by jschanck@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/70fb53e3c7be
unconditionally reset webauthn service in ActorDestroy. r=keeler
Attachment #9363371 - Attachment description: Bug 1863135 - unconditionally reset webauthn service in ActorDestroy. r=keeler → Bug 1863135 - reset webauthn service after transaction completion. r=keeler
Pushed by jschanck@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/433e66999d97
reset webauthn service after transaction completion. r=keeler

https://hg.mozilla.org/mozilla-central/rev/433e66999d97

Status: ASSIGNED → RESOLVED
Closed: 7 months ago
status-firefox121: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch
Flags: needinfo?(jschanck)

(In reply to Atila Butkovits from comment #7)

Backed out for causing failures at test_webauthn_serialization.html.

Backout link: https://hg.mozilla.org/integration/autoland/rev/7519c7ad189bf4e5fffc4bd9d166df59e5984d22

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=70fb53e3c7bec8789cfa5ea7cd292d49da25df0b&selectedTaskRun=SDnSQSv-TJu-RcE_NrOV7Q.0

Failure logs:
https://treeherder.mozilla.org/logviewer?job_id=436149877&repo=autoland&lineNumber=3588
https://treeherder.mozilla.org/logviewer?job_id=436148647&repo=autoland&lineNumber=3479
https://treeherder.mozilla.org/logviewer?job_id=436148750&repo=autoland&lineNumber=3529
https://treeherder.mozilla.org/logviewer?job_id=436146761&repo=autoland&lineNumber=11555

== Change summary for alert #40321 (as of Tue, 21 Nov 2023 12:56:35 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new) Performance Profiles
11% instagram loadtime windows10-64-shippable-qr cold fission webrender 1,482.56 -> 1,324.31 Before/After
10% instagram fcp windows10-64-shippable-qr cold fission webrender 218.18 -> 195.79 Before/After
9% instagram fcp windows10-64-shippable-qr bytecode-cached cold fission webrender 220.74 -> 201.23 Before/After
9% instagram FirstVisualChange windows10-64-shippable-qr cold fission webrender 242.82 -> 221.72 Before/After
6% instagram LastVisualChange windows10-64-shippable-qr bytecode-cached cold fission webrender 1,464.35 -> 1,380.55 Before/After
... ... ... ... ... ...
3% instagram ContentfulSpeedIndex windows10-64-shippable-qr cold fission webrender 957.82 -> 927.72 Before/After

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=40321

Keywords: perf-alert
Flags: qe-verify+

I reproduced the issue using old Nightly build from 2023-11-04 on a Ubuntu 22.04 VM and Kubuntu 23.10 VM, after closing Firefox the process stays active in System monitor and closes only after ~1 minute.
Unfortunately using latest Nightly 122.0a1 from today 2023-12-14 and Firefox 121.0 RC I get the exact same behavior. I also tried with Firefox 117.0.1 and indeed the process closes almost immediately after I close Firefox on both Linux VMs listed above.

Flags: needinfo?(jschanck)

Hm, I'm confused as to why the patch was working for me in manual testing. It's failing for me now too. I'll post another patch.

Status: RESOLVED → REOPENED
Flags: needinfo?(jschanck)
Resolution: FIXED → ---
Severity: -- → S3
status-firefox121: fixed → affected
status-firefox122: --- → affected
Priority: -- → P2

I'm inclined to wait until Fx123 to land the second patch here. We can uplift to beta 122 once it's verified fixed in 123.

Pushed by jschanck@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7a13d9641900
part 2: reset USB token manager even when there is no pending transaction. r=keeler

https://hg.mozilla.org/mozilla-central/rev/7a13d9641900

Status: REOPENED → RESOLVED
Closed: 7 months ago → 6 months ago
status-firefox123: --- → fixed
Resolution: --- → FIXED

fwiw, i've had a user confirming successfully testing https://phabricator.services.mozilla.com/D196466 on top of 121.0b9, eg "device freeing up immediately after authentification". I've asked them to report their testing here.

Comment on attachment 9368713 [details]
Bug 1863135 - part 2: reset USB token manager even when there is no pending transaction. r=keeler

Beta/Release Uplift Approval Request

  • User impact if declined: After using a USB security key, Firefox may not close immediately and other applications may not be able to use the security key.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Bogdan Maris has steps to reproduce.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Not risky. Small patch that affects a relatively rare code path.
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9368713 - Flags: approval-mozilla-beta?
QA Whiteboard: [qa-triaged]

Comment on attachment 9368713 [details]
Bug 1863135 - part 2: reset USB token manager even when there is no pending transaction. r=keeler

Approved for 122.0b3

Attachment #9368713 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

I was able to reproduce the issue on Ubuntu22.04 using FF build RC 121.0.
Verified as fixed on Ubuntu22.04 using FF build 123.0a1 (2023-12-21). Waiting for Beta 122.0b3 to check.

status-firefox123: fixed → verified

:jschanck 121 is marked as affected - should this ride the train with 122, or should it need 121 release uplift consideration?

Flags: needinfo?(jschanck)

I think this is a good candidate for a 121 release uplift.

Flags: needinfo?(jschanck)

Verified fixed using Firefox 122.0b3 on Ubuntu 22.04.

status-firefox122: fixed → verified

Please nominate this for release approval if you think it's a good candidate for a dot release ride-along.

Flags: needinfo?(jschanck)

Comment on attachment 9368713 [details]
Bug 1863135 - part 2: reset USB token manager even when there is no pending transaction. r=keeler

Beta/Release Uplift Approval Request

  • User impact if declined: see above
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: already done
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): see above
  • String changes made/needed:
  • Is Android affected?: No
Flags: needinfo?(jschanck)
Attachment #9368713 - Flags: approval-mozilla-release?

Comment on attachment 9368713 [details]
Bug 1863135 - part 2: reset USB token manager even when there is no pending transaction. r=keeler

Approved for 121.0.1

Attachment #9368713 - Flags: approval-mozilla-release? → approval-mozilla-release+

Also verified as fixed using latest Release build from treeherder 121.0.1 on Ubuntu 22.04.

Status: RESOLVED → VERIFIED
status-firefox121: fixed → verified
Flags: qe-verify+

Added to the 121.0.1 relnotes:

Fixed Firefox not closing properly and other applications being unable to use a USB security key after being previously used during a Firefox session

relnote-firefox: --- → 121+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: