Closed
Bug 1367120
Opened 7 years ago
Closed 7 years ago
[IDN Phishing] Use the "xn--chu" character to hide the real URL
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: kontakt, Unassigned)
References
Details
Attachments
(1 file)
52.40 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170517122419 Steps to reproduce: Analysis has shown that there is a possibility to use the "xn--chu" character to hide the real domain address. The "xn--chu" character allows to use spaces in the address. Example (url bar): google.com .com Simple Code: <a href="http://google.xn--com-chuaaa.com">link</a> Attackers can register a new domain or create subdomains on their own hosting. Actual results: PoC: <a href="http://google.xn--com-chuaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.com">link</a> Expected results: Recommendation: The browser should truncate all "spacing" characters in the domain name.
Comment 1•7 years ago
|
||
I can also reproduce on OS X (reporter seems to be on Windows). My IDN-fu is terrible, but it seems like the spaces in the string in question are for https://codepoints.net/U+18AA?lang=en - is that right? Jonathan, is this just fonts being terrible, or should this be treated as a space by something that isn't? Also, the internet seems to suggest this is a Mongolian script character, and so why isn't this tripping mixed script detection?
Flags: needinfo?(jfkthame)
Comment 2•7 years ago
|
||
I see a string of Mongolian letters (also on OS X, but I probably have extra fonts installed). So yes, if you're seeing blank spaces (not tofu boxes, not hexboxes, not actual Mongolian characters) then you must be getting a bogus font that claims to support the codepoint but maps it to a blank glyph. FWIW, Mongolian is classified as an "aspirational" script in UAX#31,[1] which is how it comes to be allowed in the Moderately Restrictive profile as described in UTS#39.[2] However, a forthcoming update to UAX#31[3] is expected to get rid of the Aspirational category, merging it with Limited, and that will exclude these characters. There's a patch pending review in bug 1364283 that will make this change, so although this isn't really a Firefox bug -- it's a font problem, apparently somewhat widespread -- it's likely to get fixed soon anyhow. :) [1] http://www.unicode.org/reports/tr31/#Aspirational_Use_Scripts [2] http://www.unicode.org/reports/tr39/#Restriction_Level_Detection [3] http://www.unicode.org/reports/tr31/tr31-26.html#Aspirational_Use_Scripts
Flags: needinfo?(jfkthame)
Comment 5•7 years ago
|
||
(In reply to Artur from comment #3) > Hi, > > I found another character: > > "xn--0bf" That's another Mongolian character; if it's showing up as a blank for you, that's a fault in the font. But bug 1364283 will make it display as punycode, anyhow. (In reply to Artur from comment #4) > ...and another one: "xn-fgb" :-) And that's an extended Arabic-script character. Again, if it's blank, that's a font bug. (For me, on both OS X and Windows 10, it displays the expected "ؠ" glyph.)
Thanks for information :-) Yes, on my Mac (Sierra) it is displayed as blank space. Regards, Artur
Comment 7•7 years ago
|
||
bug 1364283 is now landed in Nightly fixing the first two cases. For the third I get the same results as Jonathan.
Group: firefox-core-security → core-security-release
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Component: Untriaged → Networking
Depends on: CVE-2017-7764
Product: Firefox → Core
Resolution: --- → WORKSFORME
Comment 9•7 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #7) > bug 1364283 is now landed in Nightly fixing the first two cases. For the > third I get the same results as Jonathan. FWIW, I also see a space (OS X Sierra, fully updated) at the bottom of Jonathan's comment here: I wonder if we should check the font(In reply to Jonathan Kew (:jfkthame) from comment #5) > (In reply to Artur from comment #4) > > ...and another one: "xn-fgb" :-) > > And that's an extended Arabic-script character. Again, if it's blank, that's > a font bug. (For me, on both OS X and Windows 10, it displays the expected > "ؠ" glyph.) Jonathan, I'm still confused why this doesn't trigger mixed-script stuff (and also, I can't get this to show up in the URL bar with just 'xn-fgb') -- is it worth checking if we need to do more font blacklisting and/or look into this further?
Flags: needinfo?(jfkthame)
Comment 10•7 years ago
|
||
(In reply to :Gijs from comment #9) > Jonathan, I'm still confused why this doesn't trigger mixed-script stuff > (and also, I can't get this to show up in the URL bar with just 'xn-fgb') -- > is it worth checking if we need to do more font blacklisting and/or look > into this further? That should be "xn--fgb", clearly a typo. The "Moderately Restrictive" level (see UTS#39) allows "Latin with other Recommended or Aspirational scripts except Cyrillic and Greek", so these are not prohibited mixtures. If you change network.IDN.restriction_profile to "high", such combinations will not be allowed and will trigger punycode display instead. I suppose if we identified which fonts have the incorrect blank glyphs for these characters, we could consider blacklisting them (along the lines of bug 1360309), but given that we've just landed the patch to exclude the Aspirational script category anyway, I don't think it's worth doing more at this point.
Flags: needinfo?(jfkthame)
Reporter | ||
Comment 11•7 years ago
|
||
I'm sorry! Yes, it's "xn--fgb" :-) Thanks for help :-)
Reporter | ||
Comment 12•7 years ago
|
||
It's similar to bug 1360309 :-) Best Regards, Artur
Updated•7 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•