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

Steps to reproduce:

We identified a way to abuse WebAuthn/CTAP authentication that allows us to execute a timing attack which might lead to a serious privacy leak (e.g. account linking). The core of the issue are silent authentication calls (via CTAP) to authenticators. Silent authenticators are triggered when the allowCredentials list contains multiple key handles (credIDs). We tested a scenario where we compared the time response of invalid key handles (taken from different token) and key handles from the correct token but with a bad origin. The time difference is measurable and it increases with a bigger allowCredentials list (Please see recordings).

To reproduce the issue a specially crafted Relying Party is required (example in our source code)
https://drive.google.com/drive/folders/1pRGd8tZFFwOqF0iuDFaq1KymTmfHEWAM?usp=sharing

Actual results:

Time difference in execution of silent authentications.

We identified two existing FIDO2 hardware authenticators (HyperFido Titanium Pro and Feitian 26K) that are vulnerable to this attack. For example, for HyperFido token time difference is about 7s for 500 key handles in allowCredentials list.

Expected results:

We expected a defence mechanism preventing enumeration of allowCredential list.

Proposed solution:
As firmware update on hardware authenticators is not possible, thus we propose to introduce limits on the number of allowed key handles in allowCredentials list on client side (Firefox). Example of such a mechanism can be found in Windows WebAuthn API.

The severity field is not set for this bug.
:dveditz, could you have a look please?

For more information, please visit auto_nag documentation.

https://github.com/w3c/webauthn/issues/1701 sounds similar, addressed by proposed changes to the spec in https://github.com/w3c/webauthn/pull/1663

I'm not sure how this can be exploited in the browser. When I tried this out with my yubikey this is what happens:

1. Click login
2. The yubikey is non-responsive for a while (~20s or more depending on how many handles I picked). During this time, tapping does nothing, the browser still shows the "please tap your token" notification, and I can still cancel.
3. After that time has passed the yubikey is responsive again.
4. Once I tap it now, the process completes and I get a timing measured.

The measurement is the time that the whole process takes. However, since it requires me to wait an indeterminate amount of time before the final tap, the timing can be anything. Unless the user is constantly tapping the key until it works, the timing will include some unknown amount of time between steps #3 and #4 (assuming that the user didn't just think something went wrong and gave up and canceled the process). Because there is a human involved, this amount of time will easily be several seconds, and we can't remove this noise by repeating the process many times because each repeat requires new user interaction.

If there is no better way to exploit this in the browser, I'm changing this to sec-other.

Hi Martinho,

The way the browser processes handles, gives a way to execute FIDO authentication with many key handles (even repetitions of the same wrong key handle). Using this mechanism, it is possible to build and execute a key handle list (allowCredential list) that multiplies execution time ( it becomes measurable and user action becomes insignificant). This gives a nice channel to query the authenticator. If the authenticator has timing vulnerability (e.g. different time for keyhandle from unknown key, and different from key handle from different origin), the adversary is able to use the browser to link keyhandles, and thus break privacy guarantees of FIDO/Webauthn.

FYI Yubikey is not vulnerable to this, however we found other commercial and certified hardware roaming authenticators that are vulnerable.

Please note that the same issue was identified in Chromium and their team already implemented a fix.
https://bugs.chromium.org/p/chromium/issues/detail?id=1248862
CVE-2021-38022

Please also find our publication that describes this problem in more detail and proposes mitigations.
https://bugzilla.mozilla.org/attachment.cgi?id=9273989

Limit length of allowCredentials set r=dveditz
https://hg.mozilla.org/integration/autoland/rev/fa859ac8796d6bd303527e362cd546d2000bae30
https://hg.mozilla.org/mozilla-central/rev/fa859ac8796d

Please nominate this for Beta and ESR approval when you get a chance.

Changing the priority to P1 as the bug is tracked by a release manager for the current beta.
See Triage for Bugzilla for more information.
If you disagree, please discuss with a release manager.

Comment on attachment 9274646 [details]
Bug 1730434 - Limit length of allowCredentials set r?dveditz

Beta/Release Uplift Approval Request

• User impact if declined: Some users remain vulnerable to the privacy leak
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• 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): The patch doesn't affect behaviour for websites/accounts that aren't pathological (i.e. with 20+ webauthn credentials for the same account)
• String changes made/needed:
• Is Android affected?: Unknown

Comment on attachment 9274646 [details]
Bug 1730434 - Limit length of allowCredentials set r?dveditz

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This feature is more likely to be used by an enterprise audience, so they are disproportionately affected by this vulnerability.
• User impact if declined: Some users will be vulnerable to a privacy leak
• Fix Landed on Version: Nightly
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch doesn't affect behaviour for websites/accounts that aren't pathological (i.e. with 20+ webauthn credentials for the same account)

Comment on attachment 9274646 [details]
Bug 1730434 - Limit length of allowCredentials set r?dveditz

Approved for 101.0b7 and 91.10esr.

https://hg.mozilla.org/releases/mozilla-beta/rev/5446f8872e3d
https://hg.mozilla.org/releases/mozilla-esr91/rev/9dc9761909b4

Looks like the paper is public as of last week: https://arxiv.org/abs/2205.08071