Security/Reviews/Firefox/Graphite
From MozillaWiki
Introduce Feature
Graphite https://wiki.mozilla.org/Features/Platform/Graphite_font_shaping https://bugzilla.mozilla.org/show_bug.cgi?id=631479 Does Graphite have its own font format? Does Graphite replace OpenType, or is OpenType still used for some fonts? Do other browsers use Graphite or support Graphite fonts? No, but LibreOffice does.
- smart font / font shaping technology; similiarity to opentype
- key diff: opentype assumption is a piece of code somewhere understands the rules of the script and layout to render properly
- this is especially true of asian script type fonts
- opentype does not have all that is needed for these script type languages, thus support for font designers is limited
- instead of getting additions to the OS to support a font, graphite can support it at an application level to support the font/language
- graphite uses same font structure of opentype and truetype but has a few other items for further support
- a font can have both opentype and graphite tables, but a layout engine would use one or the other (we'd probably prefer graphite in this case)
- we would then have three ways each font can go: native APIs, harfbuzz, or graphite. (We already choose between native APIs and harfbuzz based on the script and the processing needed)
- using an upstream library instead of implementing ourselves
- thus has threats of errors in code being taken downstream (we have similiar issues with Angle)
- graphite was developed by SIL with speed and robustness in mind, but so far only used in office software rather than client software.
- pref to disable?
- yes
- likely preffed off by default until more confidence grown
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- want more font capabilities for non-western languages/fonts with support not dependant on the OS
What solutions/approaches were considered other than the proposed solution?
- could continue to support at OS level but then we are dependant on OS manufactures
- they may not have a good impetus to support smaller language/font classes
Why was this solution chosen?
- see above
Any security threats already considered in the design and why?
- none done by us
- christoph has been fuzzing graphite. some bugs have already been fixed upstream.
- found some bugs with simple fuzzing, now working on a better fuzzer
- consider adding random font feature properties to testcases (not just mutated fonts)
- christoph has been fuzzing graphite. some bugs have already been fixed upstream.
- virtual machine
- bounds checked (before being run?)
- limited language
- no loops
- heap memory only?
Threat Brainstorming
- what are the inputs?
- font file
- text
- specified language (usually an HTML attribute, but can be -moz-font-language-override), but this isn't all that interesting on its own because you're just choosing among things offered by the font
- -moz-font-feature-settings
- fonts can make up their own features, but it's expected to be a 4-letter tag. they're just labels; they don't correspond to code in the engine, but just to labels in the font itself.
- size and rotation happen in the graphics layer
- line wrapping happens in layout based on asking the shaping engine "how big is this word?"
Conclusions / Action Items
- [uniscript]Write fonts/tests that to stress the VM in various ways (e.g. lots of passes causing exponential blowup)
- And add to automated test suites?
- And give to christoph to modify-fuzz?
- [jfkthame]Use infallible malloc (simplify OOM handling) bug 691505
- bsterne to follow up with Christoph on fuzzer enhancements