3 ms·

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

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.

WorldMaker 7y ago
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.
- cawvid 7y ago
  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. https://bugs.chromium.org/p/project-zero/issues/detail?id=1399 https://bugs.chromium.org/p/project-zero/issues/detail?id=13... (description of an old ATMFD bug) explains it: "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." https://census-labs.com/media/windows_10_rs2_rs3_exploitation_primitives.pdf https://census-labs.com/media/windows_10_rs2_rs3_exploitatio... has some more detail on how this process is further hardened with syscall filtering, if I recall correctly this was introduced in Windows 10 1709: "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."
  - WorldMaker 7y ago
    I appreciate the details.

WorldMaker 7y ago

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.

cawvid 7y ago
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. https://bugs.chromium.org/p/project-zero/issues/detail?id=1399 https://bugs.chromium.org/p/project-zero/issues/detail?id=13... (description of an old ATMFD bug) explains it: "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." https://census-labs.com/media/windows_10_rs2_rs3_exploitation_primitives.pdf https://census-labs.com/media/windows_10_rs2_rs3_exploitatio... has some more detail on how this process is further hardened with syscall filtering, if I recall correctly this was introduced in Windows 10 1709: "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."
- WorldMaker 7y ago
  I appreciate the details.