Like all attempted, coordinated vulnerability disclosures, it started with the discovery of a vulnerability, in this case a vulnerability researched by one of our Senior Security Specialists Behzad Najjarpour Jabbari.
The vulnerability is a ”Denial of Service” (DoS) vulnerability within Microsoft Windows that is triggered through a stack exhaustion during the Type 1 font  processing within the Adobe Type Manager Font Driver library (AMTFD.dll), which results in a crash of the Microsoft Windows operating system. The vulnerability is confirmed on a fully-patched Microsoft Windows 7 Professional running with AMTFD.dll version 126.96.36.199 and is triggered through a specially crafted Type 1 font file.
Exploitation vectors concerning font related vulnerabilities vary in Microsoft Windows driven systems, for example the Internet Explorer may provide a convenient way to exploit certain font type vulnerabilities if a victim browses a malicious internet page, however, in the case of this vulnerability it is triggered by viewing the contents of a directory on the file system or on a share through the Explorer, where the directory contains a specially crafted font file.
We reported the vulnerability on March 7, 2017 including a “Proof of Concept” (PoC) font file towards the vendor Microsoft to attempt a coordinated disclosure of the vulnerability and its fixes.
While the first part of the coordination went as usual and as expected, on April 10, 2017 the vendor Microsoft notified us that “[…] We have determined the issue is a local authenticated DoS without a remote attack vector. As such, it does not meet the bar for servicing down level. […]”.
We do not agree with the premise the vendor Microsoft presents and argue that a specially crafted Type 1 font file does not necessarily require the attacker to have a local authenticated user account as the effect of the font file may reach the victim through viewing a directory on a network share for example. Additionally, while a victim of course needs to view a directory containing a specially crafted font file, this action constitutes one of the most basic interactions a victim performs on a system running Microsoft Windows and doesn’t present an additional obstacle.
Such a font file may enter a corporate entity through various means, be it that it is actively downloaded from the Internet or saved from an email by an employee with access to a directory on a network share or that it ended up in such a directory through some form of automatic processing when extracting archives or similar. Thus, an attacker may not require direct access to such a network share that is accessible by the victim and as such the attacker would not even be considered a part of the same corporate entity as the victim. Regardless, the attacker position is considered “remote” and not “local” in these scenarios.
In the end, it is quite believable that such a font file will not be assessed as suspicious prior to it ending up in a directory, where just the view of the directory in the Explorer then triggers the crash of the Microsoft Windows operating system.
Naturally, we communicated our point of view to the vendor Microsoft to ultimately achieve a fix of the vulnerability for the benefit of both Flexera’s and Microsoft’s customers. However, the initial statement of the vulnerability not meeting the bar for servicing down level has not been reverted by Microsoft so far.
As we received no indication from Microsoft concerning a fix of the vulnerability actively happening during the timeline outlined by our disclosure policy , we ultimately had to set the preliminary disclosure date for the vulnerability to April 24, 2017 – regardless of existence of a patch or not. We still presented the vendor Microsoft the opportunity to have the preliminary disclosure date adjusted, simply by Microsoft outlining a patch availability falling within the terms of our disclosure policy, but this offer was never met.
As consequence, we issued the Secunia Advisory SA75557  on April 24, 2017 and rated it as remotely exploitable and “Moderately Critical” with an “Unpatched” solution status to warn our customers about the vulnerability.
Of course, it is the prerogative of the vendor Microsoft to have a differing point of view, but we see it as our responsibility to warn our customers even in the absence of a patch in this case and we assure our customers that we will continue to adequately coordinate the vulnerabilities we discover, strife for getting them fixed by a vendor or maintainer, and warn our customers about the existence of such valid vulnerabilities.