Explorer doesn't render arbitrary user selected fonts and Segoe UI is not a PostScript font, so I don't think Explorer itself uses this component at all? (A lot of Windows should be using DirectWrite now? I don't think DirectWrite uses this component either?)
Also, the way this is written is sounds like system isolates this DLL into its own AppContainer separate from specific apps that use/rely on it (and I guess remote to it)?
I found answers to some of my questions on my own:
- The AppContainers thing sounds like it directly refers to the Panes in Explorer referenced, and it sounds like it is Explorer creating the sandboxes, so they wouldn't bubble out of the Pane, so it probably is correct that versions of Windows 10 doing that don't have a lot to worry about that as an exploit vector. That probably doesn't apply to other possible vectors such as evil PDFs/Word Documents, though those generally have warnings for PostScript fonts at this point. (I glossed over the Panes as the concern for the idea it might be running in the Explorer process. Their an "extension point", so Explorer moving them into sandboxes sound like exactly what it should have done, and not surprising is what it is doing.)
- DirectWrite is considered to have parts forked, but entirely independent, from ATMFD. Some CVEs have been caught that also impacted (lightly) DirectWrite, but this doesn't sound like one.
It's a sandboxing method, and atmfd was moved into a sandbox to reduce the risk of people exploiting bugs in it. At this point it is clear that sandboxing it was worth the effort.
Fair, that link points out the Kernel hosts some sandboxes directly. I had assumed they mostly had to be opt-in at the application level (opt-out in the case of the UWP platform), given the name, and those Panes are open third-party extension points and it does seem like sandboxes should apply to anything running in them as well, so it seems a fair assumption to believe that is where they were applied.
Sadly there's functionality to show previews of fonts when browsing in explorer, which means the font is potentially loaded and used in an explorer context. The appcontainer sandbox will still work in this scenario since explorer is just the unwitting accomplice responsible for loading the font.
Yes, it sounds like Explorer is the one creating/hosting the AppContainer sandboxes specifically for these third-party capable extension points (previews), as it should have always done, which is why AppContainers are mentioned as an existing solution for this exploit.
No, the AppContainer sandbox this advisory refers to is around fontdrvhost.exe. In Windows 10, this is a sandboxed user mode process running the ATMFD code, it's created by winlogon.exe.
Before then, this ATMFD code was only in the kernel, making it a useful vector for privilege escalation.
"Windows 10 has a sandboxed user-mode font driver (fontdrvhost.exe) that doesn't have access to any sensitive information and will cleanly restart upon crashing."
"Privilege escalation exploits are on the rise, because of sandboxes. The Win32k component, a provider of system calls, has introduced win32kfilter, a filtering mechanism that cuts down the number of system calls available to sandboxed processes (thus reducing the kernel's attack surface). FontDrvHost.exe, which is the font parser, uses the 3rd
level of win32kfilter."
