3 ms·

> For systems running supported versions of Windows 10 a successful attack could only result in code execution within an AppContainer sandbox context with limit

> For systems running supported versions of Windows 10 a successful attack could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities. Which is still not good but not as bad as it could be.

saagarjha 7y ago
Isn't this code running in Windows Explorer? That sounds like it could potentially be pretty bad.
- WorldMaker 7y ago
  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)?
  - WorldMaker 7y ago
    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.
    - kevingadd 7y ago
      AppContainers have nothing to do with panes, see here: https://docs.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation https://docs.microsoft.com/en-us/windows/win32/secauthz/appc... 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.
      - WorldMaker 7y ago
        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.
  - kevingadd 7y ago
    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.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
topspin 7y ago
> Which is still not good but not as bad as it could be. Not great, not terrible. ...sorry

saagarjha 7y ago

Isn't this code running in Windows Explorer? That sounds like it could potentially be pretty bad.

WorldMaker 7y ago
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)?
- WorldMaker 7y ago
  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.
  - kevingadd 7y ago
    AppContainers have nothing to do with panes, see here: https://docs.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation https://docs.microsoft.com/en-us/windows/win32/secauthz/appc... 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.
    - WorldMaker 7y ago
      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.
- kevingadd 7y ago
  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.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]

topspin 7y ago

> Which is still not good but not as bad as it could be. Not great, not terrible. ...sorry