Hacker News Reader

Comment by Sanddancer | Hacker News Reader

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

View on HN

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

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

Reply on news.ycombinator.com