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