Issue metadata
Sign in to add a comment
|
Security: Visually-perfect domain spoofing using dotless-i plus combining mark
Reported by
jfkth...@gmail.com,
Oct 15 2017
|
||||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Any domain name that includes an accented letter "i" (such as ï or î) can be trivially spoofed using the Unicode dotless-i character "ı" followed by a combining mark, which will be visually indistinguishable from the "normal" accented letter. (This is similar to other recently-addressed spoofing risks such as diacritics that might easily be overlooked -- e.g. U+0307 on i/j/l. In such cases, however, the spoof depends on the system having poor font support that fails to render the accent in a visible position, and/or user carelessness in overlooking a small yet correctly-rendered mark. This case is in my opinion more serious, in that it provides a visually "perfect" spoof, given good font support.) VERSION Chrome Version: Version 61.0.3163.100 (Official Build) (64-bit) Operating System: macOS 10.12.1 REPRODUCTION CASE Example URLs: http://xn--nave-6pa.com (http://naïve.com, using U+00EF "i with dieresis") can be spoofed by http://xn--nave-mza04z.com (http://naı̈ve.com, where "ı̈" is the sequence U+0131 "dotless i", U+0308 "combining dieresis"). Similarly, xn--dner-0pa.com (dîner.com) vs xn--dner-lza40z.com (dı̂ner.com), and likewise for any domain name that includes an accented "i". This category of spoof is an inherent problem in Unicode, because accented "i" forms are equivalent to the dotted letter "i" (U+0069) with a combining mark; the dotless "ı" (U+0131) is a separate letter with no canonical equivalence to "i", yet when a combining mark is added, it becomes visually indistinguishable. These spoofs will therefore succeed on any system with reasonably complete font support for the combining marks in the URL bar. This applies to current versions of both Windows and macOS, at least, and likely to other systems as well. To resolve this issue, I believe any domain name that includes dotless-i followed by a combining mark above should be displayed as punycode in the browser's URL bar, instead of its Unicode IDN form.
,
Oct 16 2017
jshin I wonder if you could take a look at this bug?
,
Oct 17 2017
,
Oct 17 2017
,
Oct 17 2017
,
Oct 17 2017
See also bug 727092
,
Oct 17 2017
I'm not able to see the issues ( bug 750239 or bug 727092) mentioned above, but AFAICT the change that was applied in https://chromium-review.googlesource.com/c/chromium/src/+/709919 and references bug 750239 is only addressing the use of U+0307 COMBINING DOT ABOVE to spoof a plain letter "i". It did not resolve the issue for accented letters; a sequence like U+0131,U+0308 can still be used to spoof the letter ï (i-dieresis, U+00EF).
,
Oct 17 2017
,
Nov 10 2017
,
Nov 13 2017
> It did not resolve the issue for accented letters; a sequence like U+0131,U+0308 Which is why I de-duped this bug from bug 750239 . The crbug.com UI is confusing/misleading in that de-duping does not drop 'Merged' field while status is changed back to Assigned/Unconfirmed/Untriaged, etc. I'll block dotless-i from being followed by a combining mark for now.
,
Nov 14 2017
BTW, compared with bug 750239 , this one will affect far fewer number of domains (for now) because this is a spoofing against IDN domains. A CL is up at https://chromium-review.googlesource.com/c/chromium/src/+/767888 . This is a sub-issue of bug 727092.
,
Nov 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a30f64b4ae13255535a4947616fce484c54207df commit a30f64b4ae13255535a4947616fce484c54207df Author: Jungshik Shin <jshin@chromium.org> Date: Fri Nov 17 23:34:48 2017 Block dotless-i / j + a combining mark U+0131 (doltess i) and U+0237 (dotless j) are blocked from being followed by a combining mark in U+0300 block. Bug: 774842 Test: See the bug Change-Id: I92aac0e97233184864d060fd0f137a90b042c679 Reviewed-on: https://chromium-review.googlesource.com/767888 Commit-Queue: Jungshik Shin <jshin@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Cr-Commit-Position: refs/heads/master@{#517605} [modify] https://crrev.com/a30f64b4ae13255535a4947616fce484c54207df/components/url_formatter/idn_spoof_checker.cc [modify] https://crrev.com/a30f64b4ae13255535a4947616fce484c54207df/components/url_formatter/url_formatter_unittest.cc
,
Nov 19 2017
,
Nov 19 2017
,
Nov 28 2017
,
Dec 1 2017
*** Boilerplate reminders! *** Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing. *********************************
,
Dec 1 2017
Nice one! The Chrome VRP panel decided to award $500 for this report. A member of our finance team will be in touch to arrange for payment. Also, how would you like to be credited in our release notes?
,
Dec 1 2017
Thanks, much appreciated! FYI regarding disclosure, the Firefox equivalent of this issue was reported to Mozilla at the same time as the Chromium report here (October 15th); it was fixed in the recent Firefox 57 release, though as of now the bug report has not yet been made public. As for release notes, I'm not sure what kind of details you need... I'm "Jonathan Kew <jfkthame@gmail.com>", or whatever equivalent form you typically present things in.
,
Dec 1 2017
,
Dec 4 2017
,
Jan 22 2018
,
Jan 24 2018
,
Feb 25 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 27 2018
,
Apr 25 2018
,
Oct 5
,
Oct 19
|
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Oct 15 2017Components: UI>Browser>Omnibox UI>Internationalization
Labels: OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)