Firefox3.1/CSS Transforms Security Review

Overview

Add support for Webkit's CSS transform property, which allows websites to apply affine linear transforms to HTML elements.

Background links

• Webkit's Proposed Spec, of which this patch implements only a subset.
• Webkit's announcement of what their initial implementation covers
• Bug 435293: Add support for CSS3 Transforms

Security and Privacy

• What security issues do you address in your project?
  • None
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • CSS transforms do not use configuration files or prefs.
• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • Since CSS transforms goes through the CSS parser, the patch assumes that the CSS parser's functions to extract tokens do not themselves contain security flaws. The main attack points would be constructing a transform list whose length overflows the capacity of an array length variable (this is current guarded against) or entering data that results in a floating-point exception (also guarded against).

Exported APIs

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

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)
  • gfx, layout, content, view.

Data

• What data is read or parsed by this feature
  • CSS data.
• What is the output of this feature
  • Automatic arrays containing the computed value of that CSS data.
• What storage formats are used
  • Automatic arrays, nsCSSValueList, nsCSSValue::Array, nsStyleCoord, gfxFloat.

Reliability

• What failure modes or decision points are presented to the user?
  • Failures are redirected to CSS system through the normal parsing mechanisms.
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
  • No files to corrupt.

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.]
  • #define DEBUG_HIT will output hit test data from the nsDisplayTransform item using printf. #define UNIFIED_CONTINUATIONS will attempt to transform frames with continuations as a single unit. This second #define will result in graphical glitches given the current reflow implementation and is disabled by default. It does not, however, lead to any instability.
• What ranges for the tunable are appropriate? How are they determined?
  • None.
• 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?
  • There are several bugs that while not technically blockers, would improve the state of the transform patch. These include making any frames able to act as abs-pos containers, roc's compositor patch, and a more robust overflow rectangle computation system.
• 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?
  • No.

Review comments

• DOM apis not implemented (or reviewed)
• transforms clipped according to the frame
• scaling overflows assumed to be handled by Thebes -- need to fuzz
• need developer documentation (MDC) of the subset we're actually implementing, using the -moz- names we actually parse.