[Webkit-unassigned] [Bug 244389] New: [WebAuthn] Duplicate credential IDs sent, lockup on authenticatorGetNextAssertion

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=244389

            Bug ID: 244389
           Summary: [WebAuthn] Duplicate credential IDs sent, lockup on
                    authenticatorGetNextAssertion
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Mac (Intel)
                OS: macOS 12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: carhoffm at cisco.com

Created attachment 461881

  --> https://bugs.webkit.org/attachment.cgi?id=461881&action=review

Patches and HTML file to reproduce issue

Hello!

I have run into an issue that appears to be multi-faceted: Safari seems to be sending the same credential ID to an authenticator over CTAP2 multiple times when it is only specified once in a call to get, then is locking up in response to the invocation of the authenticatorGetNextAssertion flow.

To start: I am flashing OpenSK (https://github.com/google/OpenSK) to an nRF52840 Dongle. The dongle doesn't support direct debug access, so my debugging journey thus far has been debugging by proxy based on the LED pattern it creates when panicking. When adding logic to OpenSK that panics when at least two credentials are found in allowCredentials and the first two have the same ID (see duplicate.patch in the attachment), I see that the authenticator panics when using Safari but not Chrome. (The reproduction case can be found in repro.html in the attachment.) It therefore appears that Safari is duplicating credentials that it sends to the authenticator when only one is specified in the call to navigator.credentials.get.

Following on this, Safari seems to lock up when a peculiar chain of events occurs: when the authenticator offers additional credentials to be provided in calls to authenticatorGetNextAssertion (as may happen when a duplicate credential ID is given, since both may be considered feasible by the authenticator), the first response from the authenticator causes no visible change in the authentication window, but re-plugging the authenticator and performing the flow again causes the "Cancel" button to no longer work, leaving Safari in an unrecoverable state. lockup.patch in the attachment demonstrates this—it causes OpenSK to offer all possible credentials instead of only one (rather than only doing so for resident credentials), and with this patch Safari locks up on the second authentication attempt. Removing the functionality that leads to the authenticatorGetNextAssertion call (always saying there are no more credentials) causes this behavior to stop. Chrome handles the first authentication attempt successfully, even when multiple (distinct) credentials are present.

I've been able to reproduce this issue on Safari Technology Preview 152.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220826/54e87d0b/attachment-0001.htm>