Looking at the properties of the vulnerable dll, it's "Copyright 1983-1990, 1993-2004 Adobe Systems Inc."
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.)
> 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.
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.
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...
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).
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.
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.
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.
"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 :)
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!
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.
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.
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):
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.
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.
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.
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.
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."
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.)