Vulnerability in Microsoft Font Driver Could Allow Remote Code Execution | Hacker News Reader

Vulnerability in Microsoft Font Driver Could Allow Remote Code Execution

technet.microsoft.com

172 pointsmortenlarsen49 comments

In hindsight it's to be expected that the code doesn't do enough "safe" checks which were developed only after the famous Gates memo of 2002 (reposted by Microsoft on the 10 years anniversary of it: https://news.microsoft.com/2012/01/11/memo-from-bill-gates/ ) and probably even more so as the code is copyrighted by Adobe and not Microsoft. And even more so as "Microsoft Windows does not release any OpenType fonts natively (but has the DLL because) third-party applications could install them."

(By the way, I highly admire the traditional Windows for caring about backward compatibility. I hope this doesn't change even if it's obviously harder.)

With the other 8+ 10/10 CVEs adobe announced today, they're not exactly covering themselves in glory here...

You mean on July 14th. They published no others today, today is highly unusual since typically Microsoft only patches one Tuesday per month (and their patch day was last Tuesday).

Releasing a patch on a Monday means it is likely highly critical and weaponizable (which was the impression I got reading the release).

> Microsoft Windows does not release any OpenType fonts natively (but has the DLL because) third-party applications could install them.

I'm not sure about Windows itself, but I know for a fact that Office includes at least one OpenType font: Cambria Math. It relies on the OpenType math typesetting information (which was largely designed by Microsoft). In addition, TrueType's layout information in not sophisticated enough for many languages (e.g. Arabic), so these users are most certainly using OpenType fonts.

Do you know of any references where I could read more about font formats, like the differences between OT vs. TT, the features of each, etc.?

I know close to nothing about them.

The OT spec is the definitive document: https://www.microsoft.com/typography/otspec/otff.htm Look at the list of font tables, OpenType supports everything, but the individual formats are (to oversimplify), as follows:

- TTF = Required Tables + Tables Related to TrueType Outlines

- PostScript Flavor OTF = Required Tables + Tables Related to PostScript Outlines + Advanced Typographic Tables

- TrueType Flavor OTF = Required Tables + Tables Related to TrueType Outlines + Advanced Typographic Tables

Note that in a PostScript flavor OTF the glyph outlines are simply an entire Adobe CFF font embedded in a table. CFF is in turn a compact representation of a PostScript Type 1 font. There's an entire CFF spec too: https://partners.adobe.com/public/developer/en/font/5176.CFF...

Thanks!

I imagine that Microsoft have their own code for handling the OpenType layout tables, given that they co-developed them. OpenType fonts come in two flavours, PostScript and TrueType, depending on which format the glyph outlines use. Microsoft only ships fonts with TrueType outlines. The PostScript outlines are in CFF format, which is an Adobe technology. I expect that the Adobe code is responsible for dealing with them, especially as there is no published standard describing how to rasterize PostScript fonts with pixel accuracy.

Given that the font hinting system is turing complete, and that font ligature substitution is a bizarre regular expression system [2], my only surprise is that we haven't found more holes in font renderers. Given many of the features aren't used in regular fonts, maybe it's time we pared down font rendering to something a bit more sensible.

[2] http://ansuz.sooke.bc.ca/entry/131

While we're at it, let's move GDI out of the kernel...

I really don't see any issues specific to fonts here. For (now antiquated) performance reasons both TTF and OTF fonts use binary formats which were designed to be loaded directly into memory and accessed via pointers. It's not necessary to parse these formats in that manner but it's very convinient to do some when working in C, so we have vulnerable software. The same is true of these kinds of "mmap" binary formats in general, unless the software can validate the format of a file fully before using it, then there's significant exposure to vulnerabilities. MS Word and JPEG are both examples of such "direct to memory" formats which have had led to similar exploits.

Also note that this exploit was for Adobe's code and their fonts don't have any imperative hinting instructions (hints in CFF are purely declarative), which makes your first point moot.

OpenType Layout is most certainly used in "regular" fonts if you happen to be one of the 2+ billion people whose non-"sensible" languages can't be written without such features.

> Word and JPEG are both examples of such "direct to memory" formats

I think you mean Word and PSD, not JPEG - otherwise spot on.

JPEG exploit: https://www.f-secure.com/v-descs/ms04-028.shtml

Not saying JPEG hasn't had its share of exploits, but that the format itself isn't an example (like DOC, and PSD) of a format that can be described as "direct to memory" in the same sense. DOC and PSD are in many ways just the in-memory data structures of the apps that create them, written to disk.

http://www.joelonsoftware.com/items/2008/02/19.html

"These are binary formats, so loading a record is usually a matter of just copying (blitting) a range of bytes from disk to memory, where you end up with a C data structure you can use. There’s no lexing or parsing involved in loading a file. Lexing and parsing are orders of magnitude slower than blitting."

PSD is much the same - it's why interop with PSDs is such a challenge.

JPEG has to be parsed and decompressed - another source of problems, but not remotely in the same category.

JPEG is perfectly streamable and beside from the beginning of the file not randomly accessible. You have to iterate through all the markers to find your data, so mmap doesn't bring much advantage when parsing...

Excellent blog post by Mateusz Jurczyk of Google Project Zero on how the ATMFD DLL vulnerability was discovered and how an exploit POC was developed is here - http://j00ru.vexillium.org/?p=2520

Especially read the linked PDF if you love pain and misery but enjoy understanding complex stuff :)

I've only skimmed the PDF so far.

There was one great observation I couldn't resist repeating. The font renderer is performing various checks to validate 'n', the count of arguments passed on the stack, to a particular function. However:

   Turns out, a negative value of n passes all the checks!

Oops. It's possible to use this bug to target memory well beyond the stack. It's game over!

The best bugs are the simplest bugs.

Yeah that's true but as you will find later, it really wasn't anywhere near easy to develop an exploit that results in code execution despite of that simple bug. This one just results in BugCheck - attempted X of NX memory.

Apparently this was another find in HackingTeam's leak http://blog.trendmicro.com/trendlabs-security-intelligence/a...

I think that one was MS15-077 which is a local privilege escalation. My guess is someone at Microsoft noticed today's issue while fixing that one.

I'm surprised that font exploits aren't more common. A few years ago I wrote a font fuzzer that would periodically crash the kernel, but I didn't do as much research as I would have liked.

That sounds super mega bad.

How heavily fuzzed are font libraries on non-Microsoft platforms?

This was just the other week: http://yahoo-security.tumblr.com/post/123981052855/font-pars...

Not nearly enough apparently

iOS 8.4 security release notes: https://support.apple.com/en-us/HT204941

FontParser

Impact: Processing a maliciously crafted font file may lead to an unexpected application termination or arbitrary code execution

Apparently there was a similar vulnerability in Dec 2010 as well. What is the difference btween this and then? https://technet.microsoft.com/library/security/ms10-091

The CVE for the new one is much more descriptive about what the problem actually is: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3...

I couldn't immediately find a CVE for the old one, and Microsoft's security disclosures seem more suited towards IT pros and consumers, so they don't seem to have full details about what happened in that one.

Anybody know why I can't seem to install this update? It's not previously installed, I don't see it under the available updates, and when I download the MSU file directly (Windows8.1-KB3079904-x64.msu) it says the update isn't applicable to my computer...

Greetings! In the spirit of assuming the power cord and/or laptop battery is plugged in, you are running 64-bit Windows v8.1, correct?

And in the spirit of being helpful, you can run the following command to verify the above and see if Windows Update already auto-installed this KB (if so, it will be listed):

  systeminfo | findstr /ic:"os name" /c:"system type" /c:"3079904"

> In the spirit of assuming the power cord and/or laptop battery is plugged in

Yes

> you are running 64-bit Windows v8.1, correct?

Yes

> you can run the following command to verify the above and see if Windows Update already auto-installed this KB (if so, it will be listed)

I did, and it is not.

How many times does this have to happen? I could be missing something but why do fonts have drivers?

I'm actually a huge windows fan, so I'm not really just talking snack about them. The new universal app platform should make some stuff like this obsolete over time, I hope.

Good God. Windows Server 2003 is still under support? Why are people still running that?

I'm gonna assume this affects XP as well -- yet another reason to just ban that OS from all networks forever.

> Windows Server 2003 is still under support?

No, support ended on July 14th. And yeah, it is affected by this.

From what I've been hearing, yeah, many places are still running it on varying scales.

I remember the kernel mode TrueType font driver being part of how Duqu worked, that was in 2011. This reads like it may be the same module.

http://answers.microsoft.com/en-us/windows/forum/windows_7-s...

Why didn't Windows Update notify me immediately of the vulnerability. I have automatic updates enabled, why do I have to manually check and install updates. It's dated July 16th, so I was left vulnerable to drive-bys for 4 days. I'm so fed up with Windows and their BS attitude towards security.

Published: July 20, 2015

Mine will applied after restart.

Yeah, they were told about problems a year ago and they did absolutely nothing:

https://bugs.documentfoundation.org/show_bug.cgi?id=62764&re...

Surprised that this shows up as only Important in Windows Update on Windows 7. That's the same level of importance as given to update to Windows 10 nagware.

The article says "This security update is rated Critical for all supported releases of Microsoft Windows." - are you sure?

Before posting my original comment I ran Windows Update and it came up as important, not critical.

s/Could Allow/Allows

So, which web browsers can this be exploited through?

The browser shouldn't really matter here, Windows renders fonts on kernel-level anyway.

Not all browsers use Windows' font rendering.

I would still be concerned that a 'trivial' exploit in another browser, that would normally not lead to exploitation could cause a problem. For example user tricks chrome in to saving a file in a non-standard place, Explorer reads file and executes payload while displaying preview.

"Got an attack that only works in MS Edge but victim's in Chrome? No worries, use the microsoft-edge: protocol to jump over to that browser." https://twitter.com/ericlaw/status/622157163398430720

Both Chrome and Firefox pass web fonts through OTS [1] before rendering them, so hopefully that mitigates the threat.

[1] https://github.com/khaledhosny/ots

Is there a technical reason why this is done?

Good question. Every time there's a font vulnerability, it gets asked, and for good reason. I like this answer the best: http://seenonslash.com/node/3658

Interesting quote on their mindset at the time: "Due to the modular design of Windows NT moving Window Manager and GDI to kernel mode will make no difference to the security subsystem or to the overall security of the operating system this will also have no effect on the C2 or E3 security certification evaluation, other than making it easier to document the internal architecture of Windows NT."

From: https://msdn.microsoft.com/en-us/library/cc750820.aspx

This isn't showing in Windows update for me (Win 7 64-bit), nor under installed updates. Does Microsoft do staggered releases?

Reply on news.ycombinator.com