1689128 - Add MITIGATION_NONSYSTEM_FONT_DISABLE to sandboxed processes where possible

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, enhancement, P1)

Description

[Bob Owen (:bobowen)]

This was introduced in windows 10 and was turned on for the NPAPI process.
It appears to be enabled for all chromium child processes, so hopefully can also be for ours.
Certainly the socket, gmp and rdd processes should be fine.

Comment 1

[Bobby Holley (:bholley)]

Is this something that we could also turn off for content processes, or is it only for utility processes?

Comment 2

[Bob Owen (:bobowen)]

(In reply to Bobby Holley (:bholley) from comment #1)

Is this something that we could also turn off for content processes, or is it only for utility processes?

I'm hoping we can turn it off for all sandboxed processes, chromium appear to.

jfkthame - I think we only load fonts actually installed on the system on Windows. Does that sound correct?
Web fonts are different of course, we have to register those ourselves.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Bob Owen (:bobowen) from comment #2)

(In reply to Bobby Holley (:bholley) from comment #1)

Is this something that we could also turn off for content processes, or is it only for utility processes?

I'm hoping we can turn it off for all sandboxed processes, chromium appear to.

jfkthame - I think we only load fonts actually installed on the system on Windows. Does that sound correct?

Almost. We ship an emoji font with the browser (Twemoji Mozilla), and rely on this on Win7 as the system doesn't ship with any color-emoji support. On Win10 we recently stopped loading it by default (bug 1686274), as Segoe UI Emoji provides most of the same characters (with a different design), though we have a pref that can re-enable it. (Note that we've already had bug reports as a result of switching it off -- Segoe UI Emoji doesn't have support for the country-flag emoji -- so it appears users do notice.)

I believe the Tor browser also relies on shipping a collection of fonts with the browser, and making these available. So they might need to be able to override this.

Do we know exactly what this option means? Offhand I didn't find a clear explanation of it. Does it apply to DirectWrite APIs or only GDI?

Comment 4

[Bob Owen (:bobowen)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)

(In reply to Bob Owen (:bobowen) from comment #2)

(In reply to Bobby Holley (:bholley) from comment #1)

Is this something that we could also turn off for content processes, or is it only for utility processes?

I'm hoping we can turn it off for all sandboxed processes, chromium appear to.

jfkthame - I think we only load fonts actually installed on the system on Windows. Does that sound correct?

Almost. We ship an emoji font with the browser (Twemoji Mozilla), and rely on this on Win7 as the system doesn't ship with any color-emoji support. On Win10 we recently stopped loading it by default (bug 1686274), as Segoe UI Emoji provides most of the same characters (with a different design), though we have a pref that can re-enable it. (Note that we've already had bug reports as a result of switching it off -- Segoe UI Emoji doesn't have support for the country-flag emoji -- so it appears users do notice.)

This blocking is win10 only, so we might be OK.
Assuming the way we do web fonts still works (for DirectWrite, I guess the GDI method will be stymied by win32k lockdown either way), I wonder if we could we use that, if we do need to go back to loading this.

I believe the Tor browser also relies on shipping a collection of fonts with the browser, and making these available. So they might need to be able to override this.

Ah OK, I remember something about them limiting the fonts that could be used, but I didn't realise they shipped them/some of them.
Sure enough I can see 5 fonts on top of the emoji one in a Tor browser installation.

Do we know exactly what this option means? Offhand I didn't find a clear explanation of it. Does it apply to DirectWrite APIs or only GDI?

Yeah, the documentation is detail-lite.
I'll have to experiment, but my guess is that is will allow loading from %WINDDIR%\Fonts\ and probably from %LOCALAPPDATA%\Microsoft\Windows\Fonts\
Not sure if it will affect DirectWrite as well as GDI. It doesn't say specifically, although if it is the same mechanism as [1], then that page seems to suggest it might be just GDI. Again I'll have to try it out.

[1] https://docs.microsoft.com/en-us/windows/security/threat-protection/block-untrusted-fonts-in-enterprise

Comment 5

[Bobby Holley (:bholley)]

(In reply to Bob Owen (:bobowen) from comment #0)

This was introduced in windows 10 and was turned on for the NPAPI process.

My (hearsay) understanding is that windows 10 moved font parsing into userspace, which would mean that malicious fonts can no longer be used as a sandbox escape. As such, what benefits would this mitigation provide to Firefox?

Comment 6

[Bob Owen (:bobowen)]

(In reply to Bobby Holley (:bholley) from comment #5)

(In reply to Bob Owen (:bobowen) from comment #0)

This was introduced in windows 10 and was turned on for the NPAPI process.

My (hearsay) understanding is that windows 10 moved font parsing into userspace, which would mean that malicious fonts can no longer be used as a sandbox escape. As such, what benefits would this mitigation provide to Firefox?

Interesting, if that's true I can't immediately think of anything.
After a quick search it looks like non-installed fonts were always parsed in userspace and even installed ones are from v1703.

I suppose that exploiting the userspace parsing process might in theory give you some other possibilities for escalation of privilege, but it seems much less of a concern.
Particularly given that it looks like turning this on for the content process at the moment isn't possible.

Comment 7

[Bobby Holley (:bholley)]

I spoke with the Chrome team and they confirmed that their use of this mitigation is more belt-and-suspenders rather than an attempt to neutralize to any specific threat model.

Comment 8

[Bobby Holley (:bholley)]

(In reply to Bobby Holley (:bholley) from comment #7)

I spoke with the Chrome team and they confirmed that their use of this mitigation is more belt-and-suspenders rather than an attempt to neutralize to any specific threat model.

One bit of nuance that was added as a followup but which I forgot to record here: apparently the user-mode font process is actually slightly more-privileged than Chrome's sandboxed renderer process. Therefore a font-parsing bug can be used as an escalation into a slightly-more-privileged context. Also the UMDF process has additional privileges hardcoded in Win32k which might allow for full privilege escalation, for example there used to be a bug/feature which allows the UMDF process to create any file on disk.

Low priority in any case though.

Comment 9

[Bob Owen (:bobowen)]

Attachment: Bug 1689128: Add MITIGATION_NONSYSTEM_FONT_DISABLE to RDD, Utility, GMP and Socket processes. r=handyman!

Comment 10

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/jobs?repo=try&revision=37e0cf2c5cf733d351363cea46634ca070c744cb

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9dfd8e21fa3
Add MITIGATION_NONSYSTEM_FONT_DISABLE to RDD, Utility, GMP and Socket processes. r=handyman

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/b9dfd8e21fa3