"the attackers can choose from any of the existing file formats, most of which are extremely complex both structurally and semantically, making it very difficult to get them 100% right in implementation. If we also consider that a majority of the parsers were in a large part developed in C/C++ several decades ago, that they are easily reachable via numerous channels (websites, documents, USB sticks etc.), and that they support extensive, turing-complete virtual machine environments for running untrusted TTF/PostScript Charstring programs, it becomes clear that fonts are one of the best imaginable attack vectors..."
Would it be technically feasible to just throw out the old font formats and make a new, more limited format that's just a list of Bezier curves without all the Turing-complete stuff and rarely used features, then convert all the most widely used fonts, and finally schedule TTF for deprecation?
Those features are there because people need them. Also, any new standard runs into the xkcd 927 problem of "the one standard to rule them all actually becomes just one more standard trying to compete".
The fix is to de-turingify the font parsers. Put hard limits on how much resources any font script can use. There's probably a paper out there on how to virtualise just one part of your program - in this case the font rendering functions. Replace all function calls with RPC calls to a service running on a micro VM. If the VM crashes, pop up a message box "this font is bad" or something.
The feature causing the bug in this text is actually an experimental feature that was removed later on from the standard again and weren't really ever used.
The stack actually has a hard limit of 48 entries, but the code ensuring that the limits will be adhered to had bugs.
I see two problems with a VM approach: Font handling is performance critical code. You will have to do lots of input validation for the data that is produced, which actually is the reason for the bugs in the original code. Preventing a VM being exploited through executing it in another VM also seems kind of ironic.
What I think might be a good idea is to convert old formats/format versions into newer smaller formats/format versions inside a VM. This way you will still have speed, backward compatibility and you don't need to write additional input validation.
> What I think might be a good idea is to convert old formats/format versions into newer smaller formats/format versions inside a VM.
Yeah, I like this. Like LLVM for fonts. Generate an intermediate representation inside a sandbox. Validate the IR. Output and cache a high-speed font for your platform. It might have all sorts of LLVM-like benefits in terms of compatibility and optimization, on top of the security win.
Hinting is being phased out anyway as it was a hack to work around low pixel density.
I believe Google Fonts serves the hinted version only to Windows desktops, to save bandwidth for all the other platforms that don't need/want it. I think for many of the fonts the hints are actually auto-generated via the same code that would do it automatically to a non-hinted font on Linux.
Would it be technically feasible to just throw out the old font formats and make a new, more limited format that's just a list of Bezier curves without all the Turing-complete stuff and rarely used features, then convert all the most widely used fonts, and finally schedule TTF for deprecation?