1360309 - (CVE-2017-7763) Security issue: Domain spoofing thanks to U+0F8C rendered as space on Mac

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[Michał Bentkowski]

Attachment: Domain spoofing example

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce:

The character U+0F8C (TIBETAN SIGN INVERTED MCHU CAN) when used in a domain name in Firefox on Mac looks just like a space.

This can be abused to spoof a legitimate domain followed by a chain of the character, e.g. "accounts.google.com<U+0F8C x 52>.bntk.pl".

I have created a domain https://important-domain.google.xn--com-lumaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bntk.pl/ which is SSL-enabled and looks just like important-domain.google.com when your Firefox window is now wide enough to cover the whole address. The DNS limits makes it impossible to add arbitrary number of U+0F8C chars in the address bar. As a workaround, the attacker might add just a dot, hoping that the end-user will not notice it, for example: http://important-domain.google.xn--com-lumaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.xn--cfdaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.bntk.pl/.

I have attached a screenshot of a SSL-enabled domain using 53 U+0F8C characters.

Comment 1

[Daniel Veditz [:dveditz]]

This could reasonably be moved to Core::Networking because it's IDNA, but we seem to be doing the correct thing. It's a valid "letter" (so adding it to our IDNA blacklist is problematic) and in the examples above there is no script mixing. On Windows there's no spoofing -- this character is included in their fonts.

Chrome has the same problem which is unsurprising because we're trying to follow the same standards. Why did Apple leave this character (and others!) blank? I don't expect them to have supported everything, but unsupported codepoints should have a placeholder.

Any thoughts, Gerv?

Comment 2

[Daniel Veditz [:dveditz]]

In the "Location Bar" realm maybe there are things that could address spoofs like this -- and like the completely ascii attempts like https://paypal.com.services.blahblahblahblahblah. We do slightly highlight the base domain but it's not very noticeable. Maybe helps if you can see both parts side-by-side, but easy to forget about if the darker part is out of view.

* we could try a super-obvious highlighting scheme (different background color?) so that people have a better chance of noticing its absence.

* we could scroll super-long domains so that the base part starts in view even if that means cutting off the front of the URL. This kind of spoof is one reason earlier versions of Firefox (3.x) put the base domain in a blue box for secure origins (we worried less about spoofs of already-insecure sites).

* keep a platform-dependent list of bogus-blank letters and do something if we see those. Maybe request punycode if we encounter any? In this example Macs would get a punycode label but Windows would see IDN, and Mac would see IDN for other Tibetan IDNs that did not contain any of this handful of blank characters. Seems fair, it's not like even Tibetans will be able to distinguish one blank from another different blank.

Comment 3

[Gervase Markham [:gerv]]

* Use a font we control in the Location Bar? That might have other advantages. Do we ship a font now, for Reader Mode? Could we use it, or is it not comprehensive enough?

This is clearly a bug in the font - if the font doesn't have a glyph for a character, it shouldn't offer to render it, and the end result should be fallback to whatever total fallback font the system has, which normally renders little boxes.

Do we have a handle on the scope of the problem? Is it just this one character, or are there quite a few? Michal: how did you discover this?

Gerv

Comment 4

[Michał Bentkowski]

(In reply to Gervase Markham [:gerv] from comment #3)
> Do we have a handle on the scope of the problem? Is it just this one
> character, or are there quite a few? Michal: how did you discover this?
> 

I have created a simple script (I'm attaching it) to check what characters might be used in domain names without being transformed to punycode. Then I've had a quick glance through them and noticed that there are four that looks like a space:

f8c http://testྌ.bntk.pl
f8d http://xn--test-tzp.bntk.pl/
f8e http://xn--test-yzp.bntk.pl/
f8f http://xn--test-3zp.bntk.pl/

However, it seems that in fact only u+0f8c might be abused in domain name since the other ones are transformed to punycode if there are at least two of them in sequence (for example: http://test<u+0f8d><u+0f8d>.bntk.pl/ --> http://xn--test-tzpa.bntk.pl/.

Comment 5

[Michał Bentkowski]

Attachment: Script to find non-punycode domain names

Comment 6

[Gervase Markham [:gerv]]

Are we able to find out which font on the Mac has this problem?

CCing Jonathan Kew. Jonathan: can we fix this in our font code somewhere so we don't pick the dodgy font for this character?

If that's not possible, I agree that blacklisting it (ideally, on the Mac only) is probably the simplest thing.

Gerv

Comment 7

[:Gijs (out for now; he/him)]

(In reply to Gervase Markham [:gerv] from comment #6)
> Are we able to find out which font on the Mac has this problem?
> 
> CCing Jonathan Kew. Jonathan: can we fix this in our font code somewhere so
> we don't pick the dodgy font for this character?

+ni

Comment 8

[Jonathan Kew [:jfkthame]]

On my Mac, font fallback is choosing the Simplified Chinese font "Songti SC" for this character. If I disable that font, it falls back to "Songti TC" (the Traditional Chinese version), which has the same issue; and if I disable that as well, it falls back to "STSong", which -also- has a blank glyph here.

Disabling all three of those fonts finally results in a missing-glyph hexbox instead of a blank.

I suppose we could add some code to blacklist this codepoint in those fonts, though it feels like a rather piecemeal approach to the issue.

One thing Chrome does, which we don't currently do, is to show an ellipsis (...) when the URL doesn't fit in the address bar, so there's at least *some* visual clue that it is truncated. I suspect users wouldn't usually notice this in the case where the URL appears to be quite short, then there's lots of blank space, and finally "..." at the end, so it's a pretty weak "protection", but nevertheless perhaps worth considering as a small step.

Mostly, though, I think the Location Bar should do something (e.g. scroll the URL such that the base domain is visible, and highlight it?) to help the user notice what the true origin is.

Comment 9

[:Gijs (out for now; he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #8)
> On my Mac, font fallback is choosing the Simplified Chinese font "Songti SC"
> for this character. If I disable that font, it falls back to "Songti TC"
> (the Traditional Chinese version), which has the same issue; and if I
> disable that as well, it falls back to "STSong", which -also- has a blank
> glyph here.
> 
> Disabling all three of those fonts finally results in a missing-glyph hexbox
> instead of a blank.
> 
> I suppose we could add some code to blacklist this codepoint in those fonts,
> though it feels like a rather piecemeal approach to the issue.

Huh, this is unfortunate. :-(

What do we do on Windows where this (according to comments so far - I haven't checked!) doesn't work?

> One thing Chrome does, which we don't currently do, is to show an ellipsis
> (...) when the URL doesn't fit in the address bar, so there's at least
> *some* visual clue that it is truncated. I suspect users wouldn't usually
> notice this in the case where the URL appears to be quite short, then
> there's lots of blank space, and finally "..." at the end, so it's a pretty
> weak "protection", but nevertheless perhaps worth considering as a small
> step.

Yeah, I don't think this helps "normal" users, even if it would make power users feel better (maybe) about this type of attack, so I'm not convinced it's worth implementing, also because it's not trivial to do, so the cost/gain ratio is pretty bad.

> Mostly, though, I think the Location Bar should do something (e.g. scroll
> the URL such that the base domain is visible, and highlight it?) to help the
> user notice what the true origin is.

I'm not aware of a good way to know how far to 'scroll' a textbox to show a given substring of its value. A lot of the ways of scrolling the textbox also involve modifying the selection (which breaks some user workflows) and/or hiding the selection/cursor (ie if not modifying it, but scrolling the textbox), neither of which is really very nice.

Finally, it's not clear what happens when the base domain is longer than what we can display (ie if the domain is long and/or the url bar is narrow). Cropping anything will just leave us open to spoofing based on the remaining part.

Ironically, we currently go to some lengths to scroll the textbox to the *beginning* in various circumstances, to avoid spoofs that do the opposite and append fake information after the main domain...


Given all of that, I don't see a lot of good options beyond the nuclear Safari one - when the URL bar is not focused, display *only* the base domain.

Comment 10

[Gervase Markham [:gerv]]

Do we have a conduit into Apple for reporting font bugs?

Regardless, this isn't going to get fixed any time soon. I suspect what solution we go for depends on what engineering resources we have available to us, but if we have to do the minimum effort solution, I'd be happy with a Mac-specific pref (can you append to prefs using our macro system?) to blacklist this single character.

Gerv

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to :Gijs from comment #9)
> What do we do on Windows where this (according to comments so far - I
> haven't checked!) doesn't work?

We don't "do" anything; Windows (presumably) just doesn't ship with a font that has a blank glyph at this (non-blank) character position. So users see either the proper (visible) glyph, or if no font supporting the character is present, a hexbox.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: Work around some broken Apple fonts

Here's a patch that will make us render hexboxes instead of spurious blank glyphs on macOS for the affected characters here.

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to Gervase Markham [:gerv] from comment #10)
> Do we have a conduit into Apple for reporting font bugs?

Not really, aside from filing a Radar bug report.

> Regardless, this isn't going to get fixed any time soon.

Indeed. And even if/when it does get fixed, that won't help users on existing OS versions that (past experience says) won't get updated fonts; it will only benefit future versions.

Comment 14

[Jonathan Kew [:jfkthame]]

FWIW, I filed issue 31936967 at bugreport.apple.com.

Comment 15

[Jonathan Kew [:jfkthame]]

Comment on attachment 8863754 [details] [diff] [review]
Work around some broken Apple fonts

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
The patch identifies specific characters that may display incorrectly; from there to using those characters in a spoofed domain name is a pretty trivial step.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Pretty much: we're blacklisting specific characters in specific fonts, which is hard to disguise. The only slightly obscure thing is the idea that it might be possible to use these as part of a domain name.

Which older supported branches are affected by this flaw?
All

If not all supported branches, which bug introduced the flaw?
It's not our bug, it's a fault in Apple's fonts.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
Patch should transplant easily to all branches.

How likely is this patch to cause regressions; how much testing does it need?
Minimal risk.

Comment 16

[Daniel Veditz [:dveditz]]

We've called this kind of spoof "sec-high" at times, "sec-moderate" other times. This is at the low end of sec-high I guess since it's only one platform and not really our bug, but it's not wrong to say this could be a convincing spoof.

Comment 17

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8863754 [details] [diff] [review]
Work around some broken Apple fonts

Sec-approval+. We'll want this on Beta and ESR52 as well.

Comment 18

[:Gijs (out for now; he/him)]

Has this been reported to chromium as well and do we need to coordinate anything with them in terms of disclosure when this lands?

Comment 19

[Michał Bentkowski]

(In reply to :Gijs from comment #18)
> Has this been reported to chromium as well and do we need to coordinate
> anything with them in terms of disclosure when this lands?

Yes, it's been reported to Chromium. However they haven't decided to take any action on it yet, besides reporting the font bug to Apple.

They consider the blacklisting though (and I additionally urged them to do so) so I guess they'll go this way soon.

Not sure how your coordination with Chromium works, but if you need to specify a concrete bug in communication with them, here it is: https://bugs.chromium.org/p/chromium/issues/detail?id=714196 (it's a private bug).

Comment 20

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/455d8ae18f2adb8eb051f0ddf84aa8f779d3c1d3
Bug 1360309 - Work around some broken Apple fonts. r=jrmuizel

Comment 21

[Jonathan Kew [:jfkthame]]

Comment on attachment 8863754 [details] [diff] [review]
Work around some broken Apple fonts

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: possible domain-name spoofing
Fix Landed on Version: 55
Risk to taking this patch (and alternatives if risky): minimal risk
String or UUID changes made by this patch: none

Approval Request Comment
[Feature/Bug causing the regression]: bad Chinese fonts shipped on macOS
[User impact if declined]: possible domain-name spoofing
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: tested manually
[Needs manual test from QE? If yes, steps to reproduce]: yes, visit test URL from comment 0 and check rendering in Location Bar 
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: trivial patch just blacklists specific codepoints in a few specific fonts at the time they're loaded
[String changes made/needed]: none

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/455d8ae18f2a

Comment 23

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8863754 [details] [diff] [review]
Work around some broken Apple fonts

Sec-high, Beta54+, ESR52.2+

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d5a452ce541c
https://hg.mozilla.org/releases/mozilla-esr52/rev/c7fca0c66eac

Comment 25

[Andrei Vaida [:avaida]]

Flagging this for manual testing, instructions in Comment 21.

Comment 26

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I can confirm this issue is fixed, I verified using Fx 54.0-build 3, Fx 52.2.0esr and Fx 55.0a1(2017-06-09) on mac OS X 10.12.4.

Cheers!