There are two microsoft.com pages that relate to this situation. The problem
is that the exploit happens against the kernel (in GDI, etc.) so there is not
much to do about it in any applications.
The knowledge-base KB article is the most helpful in terms of mitigation.
Any application that handles its own TrueType font handling by other than the
Windows call that accomplish font handling and rendering need to look to see
if they have any vulnerability in their parser. This also applies to any
non-Windows support for TrueType fonts that run on the same architectures as
Windows. There's not enough public information to know what to look for. I
expect that there is cross-platform cooperation at the security-team levels on
this one.
Meanwhile, the only remedy at the moment is to apply the workarounds that
apply to Windows.
Here is what I can discern from the sketchy information:
1. The exploit requires a specially-crafted TrueType Font package.
2. The vulnerability is exploited when such a font is parsed as part of
rendering of any presentation using the Windows internal support TrueType
fonts.
3. There is a fix available at the knowledge base article. It *appears* in
my non-expert reading to prevent use of the intrinsic support for embedded
fonts, since this a potentially-appealing avenue of attack via
specially-crafted documents. Fixes to close that door, and to reopen it
later, are available at the KB article.
I suspect that the workaround has no impact on LO and OO.o operability,
although I guess the thing to do is turn on the workaround and see for sure.
I'm going to do that as soon as I do some system backups first.
- Dennis E. Hamilton
tools for document interoperability, <http://nfoWorks.org/>
dennis.hamilton@acm.org gsm: +1-206-779-9430 @orcmid
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
