Vulnerability in Microsoft Font Driver Could Allow Remote Code Execution

Re:Vulnerability in Microsoft Font Driver Could Allow Remote... by jahewson on Monday July 20, 2015 @08:38PM (#9920012)

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.

[ Parent | on HN ]

Re:Vulnerability in Microsoft Font Driver Could Allow Remote... by rogerhoward on Monday July 20, 2015 @10:36PM (#9920282)

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

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

[ Parent | on HN ]

Re:Vulnerability in Microsoft Font Driver Could Allow Remote... by pjc50 on Tuesday July 21, 2015 @05:41AM (#9921192)

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

[ Parent | on HN ]

Re:Vulnerability in Microsoft Font Driver Could Allow Remote... by rogerhoward on Tuesday July 21, 2015 @03:48PM (#9925223)

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.

[ Parent | on HN ]

Re:Vulnerability in Microsoft Font Driver Could Allow Remote... by blueflow on Tuesday July 21, 2015 @03:41AM (#9920943)

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...

[ Parent | on HN ]