Recently Kaspersky released an analysis of Duqu 2.0 and apparently the malware used a True Type Font File to exploit a critical vulnerability (CVE-2011-3402) to "jump directly into Kernel". I haven't been able to find many details on this particular vulnerability, nor on how TTFs can be used for insidious purposes. I would naively think that the code to turn font instructions into characters on the screen wouldn't need Kernel access nor would it need to be particularly complicated, but that's obviously incorrect. So what makes an evil font file capable of running arbitrary code?
Fonts are hard. It's old code. It runs in kernel mode.
Julia Wolf of FireEye, Inc. did an analysis:
- Video here: Julia Wolf, 29C3, 2012-12-29, CVE-2011-3402 Technical Analysis
PDF here: Julia Wolf, CanSecWest, 2013-03-08, Windows Kernel TrueType Font Engine Vulnerability
Gist seems to be this:
- Outlines are drawn using a Turing Complete language to manipulate the graphics state
(And that language seems to be interpreted in Kernel mode.)
- It was the length of the CVT array, stored within the True Type VM’s internal global state structure.
- As a consequence, the TrueType engine now believed that it held one hundred and twenty nine elements, rather than the original length of one.
Update 2016-06: General background at Project Zero
Google Project Zero has put together an in depth background blog post about font vulnerabilities in general:
CVE-2011-3402 from above is not mentioned, though.)
- Google Project Zero Blog, 2015-07-31, Mateusz Jurczyk, One font vulnerability to rule them all #1: Introducing the BLEND vulnerability (Archived here.)
- Google Project Zero Blog, 2016-06-27, Mateusz Jurczyk, A year of Windows kernel font fuzzing #1: the results (Archived here.)
- Google Project Zero Blog, 2016-07-01, Mateusz Jurczyk, A year of Windows kernel font fuzzing #2: the techniques (Archived here.)
- For even more in depth background detail: see the personal blog of Mateusz ‘j00ru’ Jurczyk (Archived here.)
Update 2017-01: Windows 10 Aniversary Update now parses fonts in USER mode
TechNet Blogs: 2017-01-13, Matt Oh and Elia Florio, Windows Defender ATP Research Team, Hardening Windows 10 with zero-day exploit mitigations (Archived here.)
Font parsing is now done in user mode within an AC ["AppContainer"]
(The image that contains that statement seems to be from slide 34 of this presentation: BlackHat 2016, Windows 10 Mitigation Improvements.)
TrueType fonts and OpenType fonts
TrueType fonts (TTF) and OpenType fonts (OTF) are extremely popular and widely used font systems. For many machines, TTF is the default and OTF is becoming more popular, especially as it can be used as an open source format. OTF became publicly available in 1996, and TTF has been in use long before that. The legacy code often used in drivers that support both of these font systems expose vulnerabilities like heap overflow or out-of-bounds errors – both common attack vectors for exploits that lead to malicious privilege execution.
Typically, exploits that target TTF and OTF vulnerabilities target drivers that support the use of these font file types on a computer.
In the case of CVE-2015-2426 (which Microsoft detects and blocks as Exploit:Win32/CVE-2015-2426), the exploit attempted to target a .dll driver file (atmfd.dll) used by the Windows Adobe Type Manager Library in Windows. The vulnerability was resolved with MS15-078. TrendMicro performed an analysis of this vulnerability as found in the HackingTeam exploit when their data was leaked from a data breach. NCC Group also performed a lengthy analysis of the HackingTeam exploit, which made its way into the metasploit-framework project as ms15_078_atmfd_bof.
If you can stomach the whole story, be sure to check out j00ru's talk from 44CON on Reverse Engineering and Exploiting Font Rasterizers.
CVE-2013-3128 (resolved by MS13-081) was a vulnerability in the way that OTF and TTF fonts were parsed by Microsoft programs. In such a case, attackers would embed a malicious or malformed font into a webpage that would then load or target the vulnerability and allow malware to be installed on the machine. There are Nessus and OpenVAS plugins for CVE-2013-3128 that include a related TTF vulnerability, CVE-2013-3894. Probably the reason why these two never made it into a metasploit-framework exploit module was because the same patch rollup, MS13-081 and MS13-082 included another local privilege-escalation exploit named ms13_081_track_popup_menu (similar in quality to the newer ms14_058_track_popup_menu).
If you really like font scaler engine vulnerabilities, be sure to check out the work from F13 Laboratory including their Black Hat USA 2013 - Smashing The Font Scaler Engine in Windows Kernel video and whitepaper, as well as the work from Dig Team, Black Hat USA 2014 - Understanding TOCTTOU in the Windows Kernel Font Scaler Engine video and PDF presentation.
Encapsulated PostScript (EPS) files are used to display print previews and provide other functions related to printing. Like TTF, they are ubiquitous.
The .eps file can be embedded in other files, such as a Word .docx file. The .docx file is unpacked or unzipped, the .eps file is added and referenced as an image, and the .docx file is repacked.
We’ve seen three versions of this delivery mechanism using CVE-2015-2545, which affected the PosScript filter used in Microsoft Office:
- The first version attempted to exploit CVE-2015-2545 before it was known publicly, thus making it a zero-day exploit. It used a file called resume.docx which was first seen in India. Microsoft released MS15-099 (September release) to fix the vulnerability.
- The second version attempted to bypass MS15-099 (September release) and was observed in Japan. It was mitigated by an update to MS15-099 (November release).
- The third version was observed in Korea with an unknown file name and was also mitigated by an update to MS15-099 (November release).
In an unusual manner, a metasploit-framework exploit module for this vulnerability was never created, yet one can be found in CORE IMPACT as Microsoft Office Malformed EPS File Vulnerability Exploit -- or see some views into registers and stack traces.
Technically access to kernel land memory space should not be needed to render a font, hence the existence of an exploit and patch.
The patch addressed the rendering engines need to access and create writable memory within the stack.
While that can occur in either user land memory or kernel level memory registers, this particular lack of bounds checking prior to writing to the stack allowed code execution from a malformed fon file.
Your best bet for finding the 'how' it was exploited would be to search metasploits modules. I believe there is one for it.