Skip to content

Results of my recent PostScript Charstring security research unveiled

Some months ago, I started reverse engineering and investigating the security posture of the Adobe Type Manager Font Driver (ATMFD.DLL) module, which provides support for Type 1 and OpenType fonts in the Windows kernel since Windows NT 4.0, and remains there up to this day in Windows 8.1. Specifically, I focused on the handling of so-called “Charstrings”, which are essentially binary encoded PostScript programs with a dedicated set of instructions and a specific execution environment, responsible for drawing the shape of each glyph at a particular point size. It didn’t take long to notice several important points:

  • The overall code quality of the Charstring interpreter function in ATMFD.DLL was badly low, with some bugs being clearly visible in the code at first glance. This implied that (surprisingly, considering the seemingly large amount of attention received from the security community) I entered a completely unexplored territory that others haven’t delved into, or at least publicly.
  • The kernel module used the same interpreter for both Type 1 (Type 1 fonts) and Type 2 (OpenType/CFF fonts) Charstrings, and supported every single feature that has ever been part of the specification, and plenty of undocumented ones as well – bloating the size of the function to more than 20kB (!) on the x86 platform.
  • As a result of historically strong collaboration between vendors in the early days of digital font development (the 80’s and mostly 90’s), various modern font engines have a common ancestor in Adobe’s implementation of Type 1 / OpenType fonts, including:
    • Windows GDI (i.e. ATMFD.DLL in the Windows kernel),
    • Adobe Reader (i.e. the CoolType library),
    • Microsoft DirectWrite (a library used by Internet Explorer, Google Chrome, Mozilla Firefox etc.),
    • Windows Presentation Foundation.

The above observations led me to believe that the code could be affected by one or more critical vulnerabilities, and that some of those vulnerabilities could be shared across multiple widespread desktop products, additionally elevating the potential impact of any such discovery. After several weeks of reverse engineering and auditing the interpreter for vulnerabilities, I have ended up with multiple low to critical severity issues, with most of the serious ones reproducing in more than one font engine. I subsequently reported all of my discoveries to the respective vendors (Microsoft and Adobe), which fixed the bugs in security bulletins MS15-021 (March), APSB15-10 (May) and  MS15-044 (May). A quick summary of the research results is shown below, with links pointing to the corresponding google-security-research bug tracker entries, containing reports with detailed analysis of the vulnerabilities together with Proof of Concept files, as they were provided to the vendors:

Microsoft Windows (ATMFD) Adobe Reader (CoolType) DirectWrite Windows Presentation Foundation
Unlimited Charstring execution CVE-2015-0074
Out-of-bounds reads from the Charstring stream CVE-2015-0087 CVE-2015-3095
Off-by-x out-of-bounds reads/writes relative to the operand stack CVE-2015-0088
Memory disclosure via uninitialized transient array CVE-2015-0089 CVE-2015-3049 CVE-2015-1670 CVE-2015-1670
Read/write-what-where in LOAD and STORE operators CVE-2015-0090
Buffer overflow in Counter Control Hints CVE-2015-0091 CVE-2015-3050
Buffer underflow due to integer overflow in STOREWV CVE-2015-0092 CVE-2015-3051
Unlimited out-of-bounds stack manipulation via BLEND operator CVE-2015-0093 CVE-2015-3052

While many of the above issues had the potential to be usable in the context of remote code execution (Adobe Reader, Windows kernel) or elevation of privileges (Windows kernel) attacks, one particular vulnerability stood out from the others, as it provided a specially crafted font with the ability to operate on any data on the thread’s stack with all instructions available in the Type 1 / Type 2 Charstring instruction set (including arithmetic, logic, conditional, and other instructions). In other words, one could reliably generate a full ROP chain on the stack within the PostScript program, with no external interaction other than loading the font in the first place.

The extremely powerful primitive provided by the vulnerability, together with the fact that it affected all supported versions of both Adobe Reader and Microsoft Windows (32-bit) – thus making it possible to create an exploit chain leading to a full system compromise with just a single bug – makes it one of the most interesting security issues I have discovered so far. Considering that 64-bit builds of Windows were not affected by that particular bug, I also devised a x64 way to achieve reliable elevation of privileges using another Charstring vulnerability (CVE-2015-0090) found during the research, which also adheres to the “100% reliability” and “all mitigations bypassed” philosophy. Since the overall exploitation process was also quite challenging and required the use of several interesting tricks, I decided to discuss it at the REcon security conference in Montreal in a talk called “One font vulnerability to rule them all: A story of cross-software ownage, shared codebases and advanced exploitation”. As I presented the research two days ago, I am now publishing the corresponding slide deck:

One font vulnerability to rule them all: A story of cross-software ownage, shared codebases and advanced exploitation (PDF, 7.78MB)

Below you can see videos showing successful exploitation of Adobe Reader 11.0.10 using the BLEND vulnerability (CVE-2015-3052), accompanied by sandbox escapes via ATMFD.DLL in the Windows Kernel, using again the BLEND vulnerability on x86 builds (CVE-2015-0093) and a “Registry Object” vulnerability on x64 builds (CVE-2015-0090).

If you are interested in font vulnerability research, be sure to keep an eye out on this and the Google Project Zero blogs, as further technical posts and/or whitepapers regarding this effort will be published there in the near future.

{ 2 } Comments

  1. Yuhong Bao | 23-Jun-15 at 17:27:27 | Permalink

    I think ATMFD was first built into Windows with Win2000. Previously a separate ATM has to be installed to get it.

  2. anyuh | 13-Jul-15 at 01:06:04 | Permalink

    could you send me a link to get adobe reader 5’s cooltype.dll debug symbol please?

{ 23 } Trackbacks

  1. […] bug – makes it one of the most interesting security issues I have discovered so far,” he says […]

  2. […] bug – makes it one of the most interesting security issues I have discovered so far,” he says […]

  3. […] Google Project Zero to jeden z naszych najlepszych branżowych towarów eksportowych. Gdy kolejny wpis na jego blogu zawiera słowa „spędziłem kilka tygodni nad inżynierią wsteczną biblioteki” to […]

  4. […] Google Project Zero researcher has publicly disclosed details on a number of patched Adobe and Microsoft vulnerabilities, including one in the Adobe Type Manager […]

  5. […] Google Project Zero researcher has publicly disclosed details on a number of patched Adobe and Microsoft vulnerabilities, including one in the Adobe Type Manager […]

  6. […] A ton of the technical material including exploit demos and PoC code has been made available by Jurczyk in the slides from talk, and his blog post. […]

  7. […] Google Project Zero researcher has publicly disclosed details on a number of patched Adobe and Microsoft vulnerabilities, including one in the Adobe Type Manager […]

  8. Really? | 2015-06-23 at 11:38:51 | Permalink

    […] Sort of related, this boils down to the Windows font rendering done by the kernel. What could go wrong with that? j00ru//vx tech blog : Results of my recent PostScript Charstring security research unveiled […]

  9. […] an article Jurczyk also shared his demonstration this month at Recon security conference and named it, “One […]

  10. […] expert Mateusz Jurczyk pomocí reverzního inženýrství objevil několik kritických zranitelností v ovladači Adobe Type Manager Font Driver (ATMFD.DLL), který […]

  11. […] a blog post the researcher also shared his presentation from the Recon security conference this month […]

  12. […] Veja todos os detalhes dessa descoberta no post realizado pelo pesquisador, incluindo dois video d… […]

  13. […] to his blog the most serious and interesting security issue he discovered so far was a really […]

  14. […] final il a présenté à la REcon 2015 ses slides (PDF) où il parle des failles importantes qu’il a trouvé et du contexte d’exploitation particulièrement agréable pour l’une des […]

  15. […] post del investigador también comparte su presentación en la conferencia de seguridad Recon este mes, […]

  16. 15 vulnerabilidades 0-day en Adobe Reader y Microsoft Windows

    El investigador del proyecto Google Project Zero, Mateusz Jurczyk, ha publicado un total de 15 vulnerabilidades críticas que afectan a Microsoft Windows y Adobe Reader. La investigación también se presentó en la Conferencia de seguridad REcon en Montre…

  17. […] Хакер Матеуш Юрчик (Mateusz [j00ru] Jurczyk) з підрозділу Google Project Zero виступив з доповіддю на конференції Recon 2015 у Монреалі, де розповів про головну діру в комп’ютерній безпеці – шрифтах. Він розкрив 15 серйозних вразливостей в Windows і Adobe Reader при рендерінгу шрифтів, в тому числі показав хак, який обходить всі механізми захисту від експлойтів. […]

  18. […] Research find many flaws in Font driver, but already patched – J00ru blog […]

  19. […] The Blog post of Jurczyk along with his presentation is available at: […]

  20. […] می توانید جزییات بیشتر این ماجرا را در وبلاگ شخصی آقای Mateusz Jurczyk از اینجا […]

  21. […] Hacking Team Leak Uncovers Another Windows Zero-Day, Fixed in Out-of-Band Patch – PATCHED – Another Microsoft vulnerability popped up this week, this one the result of the Hacking Team compromise that we discussed in last week’s post. It is a particularly nasty one, so bad that Microsoft offered a patch for it outside its normal patching schedule. Almost all versions of Windows appear to be affected. The issue resides in some code that handles Open Type fonts and, apparently, the exploit is even capable of escaping Chrome’s sandbox when the victim visits a malicious page in their browser. Both code execution and privilege escalation are possible using this vulnerability. This is the second time Microsoft has had to patch some serious issues with the Adobe Type Manager Font Driver (ATMFD) recently (other issues were reported in late June). […]

  22. […] […]

  23. […] Google Project Zero blog. The first four of them make a sort of a whitepaper accompanying the REcon slides, as they discuss the discovery and exploitation process of the BLEND vulnerability, providing some […]

Post a Comment

Your email is never published nor shared. Required fields are marked *