1759098 - WebAuthn attestation object appears to have truncated authenticator data when creating credentials

Status: VERIFIED FIXED

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

Description

[sumitraja]

Encoding of the authenticator data of the attestation object seems to have truncated resulting in invalid CBOR.

Here is the CBOR output (from cbor.me) for Firefox webAuthn create

A3                                      # map(3)
   63                                   # text(3)
      666D74                            # "fmt"
   64                                   # text(4)
      6E6F6E65                          # "none"
   67                                   # text(7)
      61747453746D74                    # "attStmt"
   A0                                   # map(0)
   68                                   # text(8)
      6175746844617461                  # "authData"
   59 0158                              # bytes(344)
      9790265872244970DD099E6070431E21CF2CC440E44837B04367EBBFAD47EBC645000000000000202E64C00F8D90D84E86F7266353B553B9BAEFBD2D9566A3342FAC1904E9313CF2A401030339010020590100E002198009E54F47D2D7CDAE184B57598080810F357107123721FEB700D3476BC322114AF0E5EBA2D6F2AA7570564537F9F3465D791567C022EC65C3EFE1176122792495A46CA84395EDE5312AB984293A8C35907AC70DD402C686C4EE28043E92F7651A8DABFB9649ADE042AEDA2828337A1412F8135015A764796662ACB8A7827309696EB16D92161C3BCE30143DC892BF88BAD41377810AE66896A4BB8EE4514518D829E2D86B12B2826997FB9CF6F7FB85A7E8F9FDB8466ECE2C8A375FD88FDE05B01D6C979C639702B8B6CDAFF2AAEC1E609151CC43FEDD5D9F57EC050B2C53616EE220DE986490AFAE59A9216640E4C5FB68169C6849885DEACE60889D2143010001 # "\x97\x90&Xr$Ip\xDD\t\x9E`pC\u001E!\xCF,\xC4@\xE4H7\xB0Cg뿭G\xEB\xC6E\u0000\u0000\u0000\u0000\u0000\u0000 .d\xC0\u000F\x8D\x90\xD8N\x86\xF7&cS\xB5S\xB9\xBA\xEF\xBD-\x95f\xA34/\xAC\u0019\u0004\xE91<\xF2\xA4\u0001\u0003\u00039\u0001\u0000 Y\u0001\u0000\xE0\u0002\u0019\x80\t\xE5OG\xD2\xD7ͮ\u0018KWY\x80\x80\x81\u000F5q\a\u00127!\xFE\xB7\u0000\xD3Gk\xC3\"\u0011J\xF0\xE5\xEB\xA2\xD6\xF2\xAAupVE7\xF9\xF3F]y\u0015g\xC0\"\xECe\xC3\xEF\xE1\u0017a\"y$\x95\xA4l\xA8C\x95\xED\xE51*\xB9\x84):\x8C5\x90z\xC7\r\xD4\u0002Ɔ\xC4\xEE(\u0004>\x92\xF7e\u001A\x8D\xAB\xFB\x96I\xAD\xE0B\xAE\xDA((3z\u0014\u0012\xF8\u0013P\u0015\xA7dyfb\xAC\xB8\xA7\x82s\tin\xB1m\x92\u0016\u001C;\xCE0\u0014=Ȓ\xBF\x88\xBA\xD4\u0013w\x81\n\xE6h\x96\xA4\xBB\x8E\xE4QE\u0018\xD8)\xE2\xD8k\u0012\xB2\x82i\x97\xFB\x9C\xF6\xF7\xFB\x85\xA7\xE8\xF9\xFD\xB8Fn\xCE,\x8A7_؏\xDE\u0005\xB0\u001Dl\x97\x9Cc\x97\u0002\xB8\xB6ͯ\xF2\xAA\xEC\u001E`\x91Q\xCCC\xFE\xDD]\x9FW\xEC\u0005\v,San\xE2 ޘd\x90\xAF\xAEY\xA9!f@\xE4\xC5\xFBh\u0016\x9ChI\x88]\xEA\xCE`\x88\x9D!C\u0001\u0000\u0001"

From the same windows machine here is the attestation object from Edge:

A3                                      # map(3)
   63                                   # text(3)
      666D74                            # "fmt"
   64                                   # text(4)
      6E6F6E65                          # "none"
   67                                   # text(7)
      61747453746D74                    # "attStmt"
   A0                                   # map(0)
   68                                   # text(8)
      6175746844617461                  # "authData"
   59 0167                              # bytes(359)
      9790265872244970DD099E6070431E21CF2CC440E44837B04367EBBFAD47EBC64500000000000000000000000000000000000000000020E7E61911BC1357C4D548B219D701A9AC0710E7B10E589A40B6A2FD480C546866A401030339010020590100C47F02F2D8F41BBFFFDE58CAF2071D546752256AEE85433527D43FD31A5EA13783E5EAAE398B8FD90828B3538B0B01C7E122B8D39AFCD26CCFBC00D46087D70EF5D0E9DBB7B349D3805E3FEAA57FE644F2AD1E54E9691AD8EC1C816E355641DE6C192CB13ECCF4E166ED4E1DB8B492295115281CF1B55D7C2BD7B0EE235759122DF501A0BEFD6D6EEA1E995DAE308093B57C389F3C1612E80078CCE9A8488BABC222A4E5C08BB323CFAABD67A678CCCBF354981B4D2BBFAD3C4BAA40E508441F6AF5F6E37DE527284236A6AB6F6D3BE2A9DAE1766EB71FBC9B4B2224317A42B00AA881C16650EF4948309FC191CF422DF120AD57D60DE0D62881293FCFB782092143010001 # "\x97\x90&Xr$Ip\xDD\t\x9E`pC\u001E!\xCF,\xC4@\xE4H7\xB0Cg뿭G\xEB\xC6E\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000 \xE7\xE6\u0019\u0011\xBC\u0013W\xC4\xD5H\xB2\u0019\xD7\u0001\xA9\xAC\a\u0010\xE7\xB1\u000EX\x9A@\xB6\xA2\xFDH\fThf\xA4\u0001\u0003\u00039\u0001\u0000 Y\u0001\u0000\xC4\u007F\u0002\xF2\xD8\xF4\e\xBF\xFF\xDEX\xCA\xF2\a\u001DTgR%j\xEE\x85C5'\xD4?\xD3\u001A^\xA17\x83\xE5\xEA\xAE9\x8B\x8F\xD9\b(\xB3S\x8B\v\u0001\xC7\xE1\"\xB8Ӛ\xFC\xD2lϼ\u0000\xD4`\x87\xD7\u000E\xF5\xD0\xE9۷\xB3IӀ^?\xEA\xA5\u007F\xE6D\xF2\xAD\u001ET\xE9i\u001A\xD8\xEC\u001C\x81n5VA\xDEl\u0019,\xB1>\xCC\xF4\xE1f\xEDN\u001D\xB8\xB4\x92)Q\u0015(\u001C\xF1\xB5]|+װ\xEE#WY\u0012-\xF5\u0001\xA0\xBE\xFDmn\xEA\u001E\x99]\xAE0\x80\x93\xB5|8\x9F<\u0016\u0012\xE8\u0000x\xCC\xE9\xA8H\x8B\xAB\xC2\"\xA4\xE5\xC0\x8B\xB3#Ϫ\xBDg\xA6x\xCC\xCB\xF3T\x98\eM+\xBF\xAD<K\xAA@\xE5\bD\u001Fj\xF5\xF6\xE3}\xE5'(B6\xA6\xABom;\xE2\xA9\xDA\xE1vn\xB7\u001F\xBC\x9BK\"$1zB\xB0\n\xA8\x81\xC1fP\xEFIH0\x9F\xC1\x91\xCFB-\xF1 \xADW\xD6\r\xE0\xD6(\x81)?Ϸ\x82\t!C\u0001\u0000\u0001"

The Edge version successfully decodes but the Firefox version fails as it needs more bytes (344 vs 359).

Comment 1

[maxime.besson]

I am encountering the same issue on Windows versions of Firefox 98 and Nightly (Linux version appear unaffected).

This only happens when attestation type is "none" or when attestation is not explictely requested when calling navigator.credentials.create().

The cause of the issue seems to be an incorrect serialization of the AAGUID field of the attestedCredentialData structure:
https://www.w3.org/TR/webauthn-2/#sctn-attested-credential-data

Here is the content of the attestedCredentialData structure in similar test, using a Yubico authenticator

Firefox on Linux, Chrome/edge on Windows:

# 16 byte AAGUID
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
# Credential ID length (0040) + beginning of credential ID
00000010  00 40 f7 be 96 78 2f e3  a7 50 db 9a ab 46 6f ea  |.@...x/..P...Fo.|

Windows + Firefox 98:

# AAGUID is collapsed into 00, then we see the credential ID length (0040) and the beginning of the credential ID (different on every registration)
00000000  00 00 40 50 c1 af 9b 31  cf e8 9d e6 0e b2 1a f7  |..@P...1........|

Comment 2

[R. Martinho Fernandes [:rmf]]

This might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1724659.

Comment 3

[maxime.besson]

(In reply to R. Martinho Fernandes [:rmf] from comment #2)

This might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1724659.

The underlying cause may be related, but unlike #1724659, I do not see a "packed" attestation being returned by Firefox:

  "authData": "[authData with bogus attestedCredentialData]",
  "fmt": "none",
  "attStmt": {}

(tested on https://webauthn.io/)

Comment 5

[Ilya Radostev]

Hi everyone,

Looks like we faced the same issue. I can see that severity is set to S3 which means a workaround exists. Can anyone provide any details on that?

Thanks in advance

Comment 7

[thomas]

(In reply to Ilya Radostev from comment #5)

Looks like we faced the same issue. I can see that severity is set to S3 which means a workaround exists. Can anyone provide any details on that?

You can still register with another browser, and then authenticate with Firefox.

Comment 8

[thomas]

Copy-pasting myself from https://bugzilla.mozilla.org/show_bug.cgi?id=1760898

It is probably caused by the following loc
https://github.com/mozilla/gecko-dev/blob/master/dom/webauthn/WinWebAuthnManager.cpp#L460
but the API ReplaceElementsAt is missing documentation.
Following
https://searchfox.org/mozilla-central/source/xpcom/ds/nsTArray.h#2453
it seems this API doesn't overwrite the AAGUID with 16 zeroes, like memset, but instead remove the AAGUID and replaces it with a single byte.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1724659

Comment 10

[R. Martinho Fernandes [:rmf]]

Attachment: Bug 1759098 - Fix truncated AAGUID in attestation object r=dveditz

Comment 11

[Robert Hartman]

Hello. Thank you for looking at this issue. I would like to ask a question about
• status-firefox98:wontfix
I am a bit concerned about won't fix.

Several customers we support use Firefox and they have installed Major version 98 of the browser. When a fix becomes available how do they get Firefox99 or Firefox100. For example, my Firefox browser is "Up to date" with 98.0.2 and I don't see how to get any different major version.

Is there someway to get customers to Version 99 or 100 once a fix is available?

Comment 12

[Daniel Veditz [:dveditz]]

We are about to release Firefox 99 tomorrow, and users will update. At this point it doesn't make sense to fix anything in 98 because there won't be another 98.0.x release. It's just marking the reality of the situation.

Comment 13

[Robert Hartman]

Thank you Daniel. I appreciate the feedback

Comment 14

[Daniel Veditz [:dveditz]]

[Tracking Requested - why for this release]:
This was a regression in Firefox 98 that stops many Windows users from using Web Authentication. It would be great to get this in as a ride-along for a Firefox 99 point release.

Comment 15

[Daniel Veditz [:dveditz]]

This probably affects Windows 8 also, but Windows 10 for sure; it's not limited to Windows 11

Comment 16

[fredi]

I can reproduce this using Windows 10 and Firefox 99.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/194f1d96e1ee
Fix truncated AAGUID in attestation object r=dveditz

Comment 18

[R. Martinho Fernandes [:rmf]]

This patch can be verified on Windows 10 by following the following steps

1. Set up Windows Hello to use a PIN if you don't have already, or if you don't have a YubiKey or similar security token (go to Sign-in options in the settings and click "Windows Hello PIN")
2. Visit https://webauthn.io
3. Open the developer console
4. Fill in a username, anything works. Leave the rest as is (Attestation Type: None, Authenticator Type: Unspecified).
5. Click "Register". It should pop up a Windows Hello dialog asking permission and requesting PIN (or security token).
6. After this (it might take a second or two) a pop-up on the site should display "Success! Now try logging in :)"
7. If the previous step failed there would be an error in the console. This shouldn't happen, so double-check the console to make sure (there will be a couple of log statements that the site writes, but there should be no line in red there)
8. Click "Login". It should ask for a PIN/token again and navigate to a page saying "You're logged in!"

For completeness, try also with Attestation Type: Direct and Indirect just to make sure nothing broke with those.

Comment 19

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/194f1d96e1ee

Comment 20

[Ryan VanderMeulen [:RyanVM]]

The 2022-03-30 Nightly build should also have this fix if people are interested in testing it out. Feedback would be appreciated :)

Comment 21

[Catalin Sasca, Desktop QA [:csasca]]

Was able to reproduce the issue on Firefox 99.0 under Windows 10 by following the steps provided in Comment 18.

The issue is fixed and Firefox behaves as expected on Firefox 100.0a1 (2022-03-30 treeherder build) under the same system. Aditionally I tested with the Direct and Indirect Attestation Type and no issues occurred.

Comment 22

[R. Martinho Fernandes [:rmf]]

Comment on attachment 9269202 [details]
Bug 1759098 - Fix truncated AAGUID in attestation object r=dveditz

Beta/Release Uplift Approval Request

• User impact if declined: WebAuthn won't work for some users (those running Windows 10) on some websites (those using attestation: none).
• 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: See https://bugzilla.mozilla.org/show_bug.cgi?id=1759098#c18
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a very small patch, doesn't touch any other modules, and is entirely contained in a code path that only runs specifically when the bug happens (on Windows 10 when attestation: none is requested).
• String changes made/needed:

Comment 23

[Donal Meehan [:dmeehan]]

Comment on attachment 9269202 [details]
Bug 1759098 - Fix truncated AAGUID in attestation object r=dveditz

Approved for release uplift, available on the beta channel with 99.0rc2. Thanks.

Comment 24

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-release/rev/db5b4e914e77

Comment 25

[Robert Hartman]

Hello. I just tried to download the latest nightly build (today, 3/30/2022), but the downloaded version is currently at 100.0a1 (2022-03-29) ; the issue is still present in this build . I am not sure how to get the Firefox 100.0a1 (2022-03-30 treeherder build). Anyways, I will try to repro this and provide feedback tomorrow; assuming 100.0a1 (2022-03-30) is released.

Comment 26

[Daniel Veditz [:dveditz]]

If you were behind on updates it might have downloaded a previous version in the background in the meanwhile, in which case it will prompt you to restart and apply that one before it will check again. For release and beta folks this isn't a big problem in practice, but with two "nightly" builds a day, nightly users are usually an update or three behind and need to check twice in a row to make sure they get the latest.

That said, en-US updates on aus5.mozilla.org seem to be pointing at the 2022-03-29-20-42-47 updates still, while localized updates are pointing at the 03-30 builds (I tried es-AR, in case it's inconsistent).

The correct updates can be tested from https://archive.mozilla.org/pub/firefox/nightly/2022/03/2022-03-30-09-31-58-mozilla-central/ (stick -l10n on the end to find localized builds). For convenience you can bookmark https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/

I've pinged release people to look into the update server settings.

Comment 27

[Daniel Veditz [:dveditz]]

The update problems are known, but because of all the moving parts and dependencies in the release/push process folks will just have to wait for the next build (23:30 UTC or so) to get automatic updates.

Comment 28

[Catalin Sasca, Desktop QA [:csasca]]

Verified that the issue is fixed and register-login part behaves as expected on Firefox 99.0 build 2 under Windows 10. Aditionally I tested with the Direct and Indirect Attestation Type and no issues occurred.

Comment 29

[Robert Hartman]

I tested this on Windows 11 and Windows 10 using Nightly build 100.0a1 (2022-04-01)
Registration with all Attestation Types None, Direct and Indirect ; using a Yubikey USB Cross Platform Authenticator worked.
Thanks for fixing this issue.

Comment 30

[Marco Castelluccio [:marco]]

(In reply to R. Martinho Fernandes [:rmf] from comment #22)

• User impact if declined: WebAuthn won't work for some users (those running Windows 10) on some websites (those using attestation: none).

Given the high impact, this was more of an S2 than an S3. Feel free to revert this change if you disagree.