Domain spoofing thanks to U+0F8C rendered as 'space' on Mac OS 10.11

RESOLVED FIXED in Firefox -esr52

Status

()

defect
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: jackwillzac, Assigned: jfkthame)

Tracking

({csectype-spoof, sec-moderate, sec-vector})

unspecified
Firefox 57
Unspecified
macOS
Points:
---
Bug Flags:
sec-bounty +
qe-verify -

Firefox Tracking Flags

(firefox-esr5256+ fixed, firefox55 wontfix, firefox56- fixed, firefox57- fixed)

Details

(Whiteboard: [adv-main56+][adv-esr52.4+][post-critsmash-triage])

Attachments

(1 attachment)

What exact version of MacOS are you on?
Flags: needinfo?(jackwillzac)
Gerv: there was another bug about Mac rendering a few Tibetan characters as blank spaces, but I can't find it. Do you recall?
Flags: needinfo?(gerv)
Never mind, found it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(gerv)
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2017-7763
Reopening since bug 1360309 is RESOLVED FIXED. It does appear fixed on macOS 10.12, but still shows up as blank spaces in 10.11

On 10.11 it looks like we'd also have to disable STKaiti, Kaiti SC, and Kaiti TC.

Kailasa and Kokonor claim to support Tibetan but I still get boxes when I leave those enabled; they seem fine.
Assignee: nobody → jfkthame
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Summary: Domain spoofing thanks to U+0F8C rendered as 'space' on Mac → Domain spoofing thanks to U+0F8C rendered as 'space' on Mac OS 10.11
(Assignee)

Comment 5

2 years ago
(In reply to Daniel Veditz [:dveditz] from comment #4)
> Kailasa and Kokonor claim to support Tibetan but I still get boxes when I
> leave those enabled; they seem fine.

U+08FC (and a few following characters, I think) was not part of the Tibetan block when originally encoded in Unicode (v2.0); it was added much later. As such, it's not surprising if some Tibetan fonts don't include these newer characters.
(Reporter)

Updated

2 years ago
Flags: needinfo?(jackwillzac)

Comment 6

2 years ago
(In reply to Matt Wobensmith [:mwobensmith][:matt:] from comment #1)
> What exact version of MacOS are you on?

OS X El Capitan 10.11.6 (15G31). Sorry for the delayed response :)
(Assignee)

Comment 7

2 years ago
I don't have a 10.11 system any longer to verify this, but according to comment 4 this is what we need to do. (Although the problem may be specific to 10.11, the patch is harmless for other macOS versions, as there are no versions of the Kaiti fonts where those codepoints are actually useful.)
(Assignee)

Updated

2 years ago
Attachment #8898706 - Flags: review?(jmuizelaar)
Attachment #8898706 - Flags: review?(jmuizelaar) → review+
https://hg.mozilla.org/mozilla-central/rev/ee2f48b5ea07
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57

Comment 10

2 years ago
Is this report qualified for a bounty?
(Reporter)

Comment 11

2 years ago
(I'm on vacation, that's why I Cc'd Khalil Zhani)
Looks like this could use Beta & ESR52 approval requests.

(In reply to Khalil Zhani from comment #10)
> Is this report qualified for a bounty?

https://www.mozilla.org/en-US/security/client-bug-bounty/ contains information on how to request a bounty for a submitted issue.
Flags: needinfo?(jfkthame)
(Assignee)

Comment 13

2 years ago
Comment on attachment 8898706 [details] [diff] [review]
Work around more bad fonts on older macOS

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
Not really a Gecko bug, this is a workaround for a buggy Apple font with spurious blank characters that might be used to obscure a spoofed URL. Although this does not affect the most recent macOS version (the font appears to have been fixed: the issue is present on 10.11 but not 10.12), it seems likely that a higher proportion of ESR users might also be on older OS releases and hence more likely to be affected than the general release population.

User impact if declined: Potential for URL spoofing due to invalid characters in a Chinese font shipped on older macOS releases

Fix Landed on Version: 57

Risk to taking this patch (and alternatives if risky): minimal

String or UUID changes made by this patch: none
Flags: needinfo?(jfkthame)
Attachment #8898706 - Flags: approval-mozilla-esr52?
Attachment #8898706 - Flags: approval-mozilla-beta?
Flags: sec-bounty?
(In reply to Jonathan Kew (:jfkthame) from comment #5)
> U+08FC ... was not part of the Tibetan block when originally encoded in Unicode (v2.0);
> ... [I]t's not surprising if some Tibetan fonts don't include these newer characters.

Would have been nice if they'd encoded them as reserved boxes rather than spooftastic blanks :-(
See Also: → CVE-2017-7763
Comment on attachment 8898706 [details] [diff] [review]
Work around more bad fonts on older macOS

Avoid a potential URL spoofing. Beta56+ & ESR52+.
Attachment #8898706 - Flags: approval-mozilla-esr52?
Attachment #8898706 - Flags: approval-mozilla-esr52+
Attachment #8898706 - Flags: approval-mozilla-beta?
Attachment #8898706 - Flags: approval-mozilla-beta+
Group: firefox-core-security → core-security-release
Flags: sec-bounty? → sec-bounty+
Whiteboard: [adv-main56+][adv-esr52.4+]
Flags: qe-verify-
Whiteboard: [adv-main56+][adv-esr52.4+] → [adv-main56+][adv-esr52.4+][post-critsmash-triage]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.