Firefox3.1/Downloadable Fonts Security Review: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 10: Line 10:


== Security and Privacy ==
== Security and Privacy ==
* What security issues do you address in your project?
The major concern with the introduction of this feature is that it exposes our text rendering code and the platform-specific libraries we use to attack via intentionally corrupt fonts.  Evil fonts could already cause these problems with our code currently but adding support for downloadable fonts makes this far easier.  Possible risk areas: handling font names, reading the character map, handling metrics, catching errors when drawing with bogus glyph data.  Within our source tree this could affect code within gfx/thebes, gfx/cairo and within layout code.
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
* Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
 


== Exported APIs ==
== Exported APIs ==

Revision as of 08:36, 3 September 2008

Overview

The goal of this feature is to support the CSS3 @font-face feature, which allows fonts to be downloaded when referenced within stylesheets.

Background links

Security and Privacy

The major concern with the introduction of this feature is that it exposes our text rendering code and the platform-specific libraries we use to attack via intentionally corrupt fonts. Evil fonts could already cause these problems with our code currently but adding support for downloadable fonts makes this far easier. Possible risk areas: handling font names, reading the character map, handling metrics, catching errors when drawing with bogus glyph data. Within our source tree this could affect code within gfx/thebes, gfx/cairo and within layout code.

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • Does it interoperate with a web service? How will it do so?
  • Explain the significant file formats, names, syntax, and semantics.
  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
  • Does it change any existing interfaces?


Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)


Data

  • What data is read or parsed by this feature
  • What is the output of this feature
  • What storage formats are used


Reliability

  • What failure modes or decision points are presented to the user?
  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?


Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]
  • What ranges for the tunable are appropriate? How are they determined?
  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?


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?
  • 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?


Review comments