Firefox 3.6/WOFF Security Review
Contents
Overview
Support new web font format designed to be widely acceptable to both browser developers and font vendors, to facilitate greater availability of fonts for web use, and to improve interoperability among future browser versions.
- Background links
- https://bugzilla.mozilla.org/show_bug.cgi?id=507970
- http://people.mozilla.com/~jkew/woff/woff-2009-09-16.html
Security and Privacy
- Is this feature a security feature? If it is, what security issues is it intended to resolve?
No.
- What potential security issues in your feature have you already considered and addressed?
This feature exposes us to untrusted content from web sites via CSS @font-face rules, in exactly the same way as our existing support for TrueType and OpenType fonts.
The underlying font system (platform text APIs) are somewhat protected by the new format, in that we do more validation of WOFF font data during the decoding process than we do of downloaded OpenType fonts. Therefore, once the font data is actually passed to the platform, we can have greater confidence that it is well-formed, and therefore may be less likely to trigger platform bugs in layout and rasterization.
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
N/A
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
The new format is decoded using zlib; therefore any vulnerability within zlib's decompress() function would be exposed through WOFF fonts. I am assuming that we consider zlib sufficiently mature and well tested that we are comfortable exposing it in this way.
There is new code to handle the actual WOFF file format (a collection of zlib-compressed chunks); this code could be vulnerable to buffer overflow attacks or invalid memory access leading to DoS, if offsets and block sizes are incorrect. We have tried to ensure that all such values are validated before use, checking for arithmetic overflow in offset computations as well as checking that offset/length values indicate valid data within the file.
- How are transitions in/out of Private Browsing mode handled?
N/A
Exported APIs
- Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
No APIs as such; adds support for an additional font file format in @font-face rules.
- Does it interoperate with a web service? How will it do so?
No.
- Explain the significant file formats, names, syntax, and semantics.
The WOFF format (link to specification is above) is a simple repackaging of OpenType font data, applying zlib compression to each of the tables making up the font. On downloading a WOFF font, we decode it in RAM to form a standard OpenType font structure, and then handle this with existing font code.
- Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
N/A
- Does it change any existing interfaces?
There is a change to nsIStreamLoader, adding a new success code NS_SUCCESS_ADOPTED_DATA that an observer can return from the OnStreamComplete method to indicate that it wishes to take over ownership of the data buffer; the loader will not delete it.
This change does not affect any existing users of the interface.
Module interactions
- What other modules are used (REQUIRES in the makefile, interfaces)?
No new interactions. The WOFF format is downloaded by netwerk, then handled in gfx code, in response to CSS rules from layout. All this behaves just like OpenType font support; the only difference is that the downloaded data is passed to a decoding process before being used as a platform font.
Data
- What data is read or parsed by this feature?
WOFF font files (see above).
- What is the output of this feature?
No output as such. WOFF files are converted to OpenType (sfnt) format internally for use by the platform font subsystem.
- What storage formats are used?
N/A
Reliability
- What failure modes or decision points are presented to the user?
None. Invalid font files are silently discarded (just as with existing OpenType support).
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
N/A
Configuration
- Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
No.
- Are there build options for developers? [#ifdefs, ac_add_options, etc.]
No.
- What ranges for the tunable are appropriate? How are they determined?
N/A
- What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
None.
Relationships to other projects
Are there related projects in the community?
- If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
Not in the Mozilla community. The WOFF format has been designed in cooperation with others in the font designer/vendor and W3C standards communities, and has wide approval there.
- Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?
N/A
