Firefox can't be reopened after using FIDO2 USB authentication
Categories
(Core :: DOM: Web Authentication, defect, P2)
Tracking
()
People
(Reporter: guillermox7, Assigned: jschanck)
References
Details
(Keywords: perf-alert)
Attachments
(3 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
3.29 MB,
image/gif
|
Details | |
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:
- 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.
- Go to WebAuthn.io
- Register with any username
- Close Firefox
- 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.
Comment 2•1 year ago
|
||
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.
Comment 3•1 year ago
|
||
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.
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.
Assignee | ||
Comment 5•1 year ago
|
||
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.
Updated•1 year ago
|
Comment 7•1 year ago
•
|
||
Backed out for causing failures at test_webauthn_serialization.html.
Backout link: https://hg.mozilla.org/integration/autoland/rev/7519c7ad189bf4e5fffc4bd9d166df59e5984d22
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
Updated•1 year ago
|
Comment 9•1 year ago
|
||
bugherder |
Assignee | ||
Updated•1 year ago
|
Comment 10•1 year ago
|
||
(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
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
Updated•1 year ago
|
Updated•1 year ago
|
Comment 11•1 year ago
|
||
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.
Assignee | ||
Comment 12•1 year ago
|
||
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.
Assignee | ||
Comment 13•1 year ago
|
||
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 14•1 year ago
|
||
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.
Comment 15•1 year ago
|
||
Comment 16•1 year ago
|
||
bugherder |
Comment 17•1 year ago
|
||
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.
Assignee | ||
Comment 18•1 year ago
|
||
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
Updated•1 year ago
|
Comment 19•1 year ago
|
||
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
Comment 20•1 year ago
|
||
uplift |
Updated•1 year ago
|
Comment 21•1 year ago
|
||
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.
Comment 22•1 year ago
|
||
:jschanck 121 is marked as affected - should this ride the train with 122, or should it need 121 release uplift consideration?
Assignee | ||
Comment 23•1 year ago
|
||
I think this is a good candidate for a 121 release uplift.
Comment 24•1 year ago
|
||
Verified fixed using Firefox 122.0b3 on Ubuntu 22.04.
Comment 25•1 year ago
|
||
Please nominate this for release approval if you think it's a good candidate for a dot release ride-along.
Assignee | ||
Comment 26•1 year ago
•
|
||
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
Comment 27•1 year ago
|
||
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
Comment 28•1 year ago
|
||
uplift |
Updated•1 year ago
|
Comment 29•1 year ago
|
||
Also verified as fixed using latest Release build from treeherder 121.0.1 on Ubuntu 22.04.
Comment 30•1 year ago
|
||
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
Description
•