vault/precursor freeze

[eau-u4f]

I had a usb FIDO2 (yubikey) key and the precursor plugged on the same machine. going on an internal web requesting a FIDO2 thinggy... The precursor show the following screen and freezed on it, keys were working (since backlight was triggered when trying to press any keys) but no reaction and the precursor remained stuck on this screen, F1 did not work, nor any other keys.

As I had no pin, I had to wait for battery to be empty.

[bunnie]

Oh...interesting. So just to be clear, this message popped up when the system tried to talk to the FIDO key that is plugged into the same system as the Precursor device?

The screen just appeared frozen on this, staying at '5s to abort' and no WDT was fired?

[eau-u4f]

yes, this appeared and stayed, i press F1 multiple times then any other key nothing happened, I had to wait for the battery to be empty (i had no needle to press the reset button)

[bunnie]

Gotcha. I could definitely see this being an edge case that breaks the code (two FIDO tokens and maybe a confused host software sending an approval request to our device by accident).

Did the regular FIDO token perform as expected? I'm just wondering how the packet even got routed to us in the first place.

[eau-u4f]

Yep the regular FIDO token operated normally.

[bunnie]

Thanks, I'll try to reproduce on my end, may have more questions later. Super weird that the device even got a CTAP message, because it should be routed to a given VID/PID. I don't think there's such a thing as a broadcast USB packet, so the host had to have tried to initiate the request somehow.

Can you disclose what app/method you were using to initiate the request? i.e. what browser/OS combo or command line tool.

[eau-u4f]

The app was a web based auth thing to authenticate internal to the company i work for, the browser was firefox + macOS.

[eau-u4f]

I'll try to reproduce until i pinpoint which conditions, i'll comment here if I manage to do so.

[eau-u4f]

ok simple test I just did, register another FIDO key for a simple gmail account. Plug precursor to a mac, open gmail, authenticate, FIDO request arrives press F1 to deny.. freeze on the screen shown above.

[bunnie]

After looking at the code a bit more for implementing #333, I am realizing that the problem is that CTAP1/U2F requests are polled by the host.

So what's happening here I think is the poll request is being broadcast, somehow globally; and the first thing to respond to it is clearing the poll loop.

However, when the polling goes away from the host, the actual loop inside Precursor has no more events to pump the UX loop, and so, it hangs.

Let me think about this for a bit.

[bunnie]

omg how do I get github to stop closing issues if I reference them in a commit???

Anyways: this commit adds a self-timer to any U2F transaction that will issue a close message if for some reason the host stops polling (either because another authenticator answered the query, or you unplugged the device while polling, etc.)

Unfortunately and this is why the issue should not be closed, the site that I use for testing: https://mdp.github.io/u2fdemo/# seems to no longer work. Thus I have no U2F sites to check that this is operating correctly.

Could someone either point me to a new testing site for U2F, or perhaps test that this fix works?

[bunnie]

@wizzard0 this thread got moved from your original, for some reason I can't tag you with an assignment

[bunnie]

I managed to use https://u2f.bin.coffee/ (thanks @gsora)

The test works when I unplug the device halfway through the auth -- the screen freezes on the last timeout count number, but then, the appropriate number of seconds later plus a little margin it clears.

The UX is a little unpleasant in that it hangs out with the stuck time on it, but, at least it clears once the timeout is reached.

[bunnie]

No response from users on the validity of the fix, closing for now to tidy up the issue list. Please re-open if someone gets around to testing this and they find the bug is still there.

[eau-u4f]

hello, sorry traveling, is this on the bleeding-edge ? I can test now.

[eau-u4f]

I upgraded to the latest stable, it seems the fix made its way to stable too, since I did not have a freeze with the latest stable version.

[spoelstraethan]

I ran into this issue today on 0.9.13 which iirc is the latest stable, so there is still something funky going on.

Similar scenario, I was logging into GitHub and got a prompt for a security key, Precursor doesn't yet have the credential so I plugged in my Yubikey and authenticated and the Precursor got "stuck" rather than properly timing out.

[bunnie]

Can you please provide a photograph of the frozen screen next time if you see it. I think Github uses FIDO2, not U2F, so technically this is a different code path but the issue is the same. But a photo of the frozen screen can go a long way toward making sure I'm working on the right thing.

[spoelstraethan]

I did happen to take a photo yesterday when it happened, and again today when I reproduced it again on GitHub and also when attempting to log into a Chromebook and had the Precursor plugged in to provide the password (autotype for username would be nice eventually) and then used a Yubikey for the FIDO2 portion.

I then added the Precursor as an additional security key on one of my GitHub accounts and the FIDO section of the Vault is showing as empty, but I am able to use the Precursor as a USB auth and get prompted and can accept the challenge and get logged in.

[bunnie]

That...is weird. The first screen where it hangs is a FIDO2 screen.

The thing where it requests to make an ID is a legacy U2F authentication. I thought a website is supposed to use FIDO2 if it's available. Hmm....

[spoelstraethan]

I think something I had to do for the Mooltipass and GitHub was remove ALL security keys from the account, then register it first, because that allowed it to use FIDO2 vs U2F, and then future security keys (Yubikeys) could use whatever protocol they felt like. What is really weird is that I was able to register the Precursor with GitHub on this account (that has a Mooltipass and a couple Yubikeys), and I can use it as the security key, but the vault shows up as empty for FIDO entries.

[spoelstraethan]

I have some additional findings on this that might be pertinent.

I had the Precursor and my Mooltipass plugged in, they both have a FIDO2/U2F registration for a specific GitHub account, though on the Precursor it's not showing up on the FIDO tab.

When I logged in to Github using the credentials for the account and was prompted for the security key (device identity or USB), I selected USB Security Key and received the prompt on both devices authenticate the request, i accepted it on the Mooltipass and in this case the Precursor did not freeze, the authentication prompt timed out as expected. I'll have to test some more with the Yubikey and Precursor to see if I can reproduce the lock-up I'd encountered previously.

An interesting side note is that I was actually in "Management mode" that is probably similar to the "Host readout mode" of the Precursor, though they have an option to require an on-device prompt for every change to the database in addition to a prompt to enter "Management mode". I'd entered this mode because I had to install the Moolticute management application and sync the time with the Mooltipass in order to do the FIDO2 (and any TOTP auth), since it doesn't have an accurate internal RTC.

I believe the Mooltipass currently only supports CTAP2 because they haven't done the work to pull in the additional libraries required for CTAP2.1, but they do have some limited support for resident keys iirc.