21

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?

Improve this question

3 Answers 3

Reset to default
18

Fonts are hard. It's old code. It runs in kernel mode.

Julia Wolf of FireEye, Inc. did an analysis:

Gist seems to be this:

Slide 32:

  • Outlines are drawn using a Turing Complete language to manipulate the graphics state

(And that language seems to be interpreted in Kernel mode.)

Slide 78:

  • 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:
(The specific CVE-2011-3402 from above is not mentioned, though.)

Update 2017-01: Windows 10 Aniversary Update now parses fonts in USER mode

Improve this answer
1
  • 1
    YAY! It only [sic] took them 7 years from the first confirmed use of the exploit to fix it. Too bad for ~64% of all desktop users that are still using a vulnerable OS. (assuming everyone using windows 10 got their updates)
    – Mindwin Remember Monica
    Jan 18, 2017 at 12:58
10

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

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.

Improve this answer
8
0

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.

Improve this answer
4
  • 6
    Uhm, actually with the switch to Windows NT 4 a lot of the GDI responsibilities ended up in kernel mode. This is still the case even for today's Windows versions. The reason is that context switches between kernel and user mode can be pretty expensive. Hence: technically it is needed. One can argue about the pros and cons, but the fact remains that this job is done in kernel mode for a reason.
    – 0xC0000022L
    Jun 10, 2015 at 23:43
  • I fail to see your point and any correlation.
    – jas-
    Jun 11, 2015 at 1:01
  • How would font loading clobber the memory? Don't fonts have a finite size?
    – munchkin
    Jun 11, 2015 at 5:31
  • I added a bit to address that in my answer
    – jas-
    Jun 11, 2015 at 11:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .