WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
191533
[WebAuthN] Use a real nonce for CTAPHID_INIT
https://bugs.webkit.org/show_bug.cgi?id=191533
Summary
[WebAuthN] Use a real nonce for CTAPHID_INIT
Jiewen Tan
Reported
2018-11-11 18:31:28 PST
Use a real nonce for CTAPHID_INIT.
Attachments
Patch
(20.40 KB, patch)
2018-11-14 01:34 PST
,
Jiewen Tan
no flags
Details
Formatted Diff
Diff
Patch for landing
(20.51 KB, patch)
2018-11-15 12:47 PST
,
Jiewen Tan
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Jiewen Tan
Comment 1
2018-11-14 01:34:11 PST
Created
attachment 354782
[details]
Patch
Brent Fulgham
Comment 2
2018-11-14 08:21:22 PST
Comment on
attachment 354782
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=354782&action=review
Looks good. r=me
> Source/WebKit/ChangeLog:4 > +
https://bugs.webkit.org/show_bug.cgi?id=191533
Please always include a radar for these changes.
> Source/WebKit/ChangeLog:14 > + sufficient as the arrived init response will piped in HidConnection::m_inputReports, which is designed in
"will BE piped THROUGH HidConnection::m_inputReports..."
> Source/WebKit/ChangeLog:15 > + purpose to store any data packets within (initialized, terminated) time interval to prevent data loss in
"... which is designed ON purpose to ..."
> Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidDriver.cpp:59 > + // HidConnection could hold data from other applications, and thereofore invalidate it before each transaction.
It seems like this could be the source of difficult-to-debug issues in the future, though I guess not in WebKit after this change. I wonder how other groups deal with HID connections that contain existing data.
Radar WebKit Bug Importer
Comment 3
2018-11-15 12:07:12 PST
<
rdar://problem/46103502
>
Jiewen Tan
Comment 4
2018-11-15 12:42:17 PST
Comment on
attachment 354782
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=354782&action=review
Thanks Brent for r+ this change.
>> Source/WebKit/ChangeLog:4 >> +
https://bugs.webkit.org/show_bug.cgi?id=191533
> > Please always include a radar for these changes.
Sure.
>> Source/WebKit/ChangeLog:14 >> + sufficient as the arrived init response will piped in HidConnection::m_inputReports, which is designed in > > "will BE piped THROUGH HidConnection::m_inputReports..."
Fixed.
>> Source/WebKit/ChangeLog:15 >> + purpose to store any data packets within (initialized, terminated) time interval to prevent data loss in > > "... which is designed ON purpose to ..."
Fixed.
>> Source/WebKit/UIProcess/WebAuthentication/fido/CtapHidDriver.cpp:59 >> + // HidConnection could hold data from other applications, and thereofore invalidate it before each transaction. > > It seems like this could be the source of difficult-to-debug issues in the future, though I guess not in WebKit after this change. I wonder how other groups deal with HID connections that contain existing data.
Well, actually the CTAPHID_INIT response is the only one we need to pay attention to as the channel id embedded is the same for every application. Other cmd will use a dedicated channel id which is unique per app. Chromium is kind of merging our CtapHidDriver::Worker and CtapHidDriver together, so they just keep reading the pipe when a wrong nonce arrive.This design is free of the deadlock I describe in the change log however it makes the whole driver has much more complicated states than us. At the meantime, our design is simple, CtapHidDriver::Worker only handles each transaction, it doesn't care the content of each transaction. CtapHidDriver manages all states such as channel allocation. Since the worker doesn't care the content of each transaction, it won't know the nonce of the incoming legitimate response (a completed response with a right channel id) is not the expected one, and therefore terminates the transaction. And there is no ways for CtapHidDriver to ask the worker to open a semi transaction which is read only to exhaust the pipe. Therefore, it issues a new transaction. Since the described dead lock should be a quite rare situation in real world as it requires two apps send init cmd at the same time to trigger. I couldn't image how a legitimate user would do this. Therefore, there is no need to make a huge change to tackle this particular issue.
Jiewen Tan
Comment 5
2018-11-15 12:47:12 PST
Created
attachment 354972
[details]
Patch for landing
WebKit Commit Bot
Comment 6
2018-11-15 13:25:00 PST
Comment on
attachment 354972
[details]
Patch for landing Clearing flags on attachment: 354972 Committed
r238246
: <
https://trac.webkit.org/changeset/238246
>
WebKit Commit Bot
Comment 7
2018-11-15 13:25:02 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug