Security/Reviews/Firefox7/ReviewNotes/AzureD2DCanvas: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "holding")
 
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
holding
==Items reviewed ==
* Azure Direct2D backend for Canvas - https://wiki.mozilla.org/Platform/Features/AzureD2DCanvas
 
== Introduce Feature ==
===  Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ===
* canvas was on cairo then cairo on top of direct2D
** this removes cairo and replaces with Azure
* Azure is a thinner wrapper and alows for more efficiency and better API map up
* This is Windows only
** For now?
** cairo will cont on other platforms
** & on Win where we do D2D
* Azure is an in house developed platform
* New implementation will be reachable directly through existing canvas functionality -- see also https://developer.mozilla.org/en/Drawing_Graphics_with_Canvas
=== What solutions/approaches were considered other than the proposed solution? ===
* Designed to replace cairo
* http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/
* http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo
=== Why was this solution chosen? ===
^^ see above
=== Any security threats already considered in the design and why? ===
* does not deal with content on websites, it's really in between
* no specific threats considered
* there was an info leak bug in cairo direct2D, this was taken into account {{bug|655836}}
== Understanding the scope of Azure project ==
* Canvas is (currently) the only place where Azure is a replacement. Elsewhere, it's in concert with existing code
* Do we have a listing of what will using Cairo and what will using Azure (and what will using Cairo ''through'' Azure)?
* No immediate plans to leave Cairo on nonD2D on windows, OS X will get Azure on top o core graphics, Linux will get Azure on top of Cairo
* Fonts
** Cairo doesn't really do fonts, freetype on Linux/OS X, and GDI on Win
 
== Threat Brainstorming ==
*  Are we more worried about bugs in Azure itself, or in exposing OS APIs to attack that had previously been protected by API layers atop them (e.g. stateful or range-checking)?
** both, right?
** more worried about bugs in the new canvas implementation
* Sec problems in D2D may be easier to exploit than previously as some of the layers are not there
** Would these problems be specific to graphics cards or drivers? What kind of testing matrix do we need?
*** More likely to be bugs in D2D itself
* Numerical thresholds?
** Not many around pixels. Some around arcs.
** Mostly floating point (in contrast to cairo which was mostly int), in part because D2D takes floats as input
*** The usual float concerns: NaN, Infinity, positive and negative zero, denorm, lost precision
* Does the Azure API impose limits on the size being passed? (i.e. a very large image, larger than say the screen size)
** No
* What do you do when D2D returns errors?
** Hopefully we don't draw it
** Hopefully we don't draw uninitialized memory onto the screen
** Hopefully we don't stop drawing the entire browser
** Behavior here should be verified
** D2D is restricted by texture size limits that are imposed by the graphics card
*** Normally fail if you try to create/render above limits
**** But then we fall back to a software (cairo) surface rather than giving up entirely
** We should only get errors from D2D upon canvas creation (e.g. OOM), not upon drawing crazy shapes
*** Do we have assertions to verify this?
* What happens when you resize a canvas?
** Especially when you pass the size threshold while resizing?
*** And JS still has reference to a 2dcontext object?
** Contents are lost?
* What happens when you stretch the display of a canvas?
** Not a big deal, basically goes through image-resize code.
 
== Conclusions / Action Items ==
* [bsterne] Fuzz canvas on top of Azure as a general fuzzing task
** Especially radial gradients and fuzzy shadows, since those are things "done by Azure" rather than just passed to D2D
** Is it stateless all the way down? Or does fuzzing need to take some kind of state into account?
*** Clipping is stateful. We'll often take different code paths depending on whether there's a clip or not.
** We have a few canvas fuzzers in the private fuzzing repo
** Do we have existing canvas tests in our test suite? Could be used for mutation fuzzing (mutate JavaScript that modifies canvas objects)
*[jeff] {{bug|679868}}Add assertions to verify that D2D does not return errors except upon canvas creation
* [QA?] Make sure we have regression tests for many of the questions above (e.g. what happens if you resize a canvas from tiny to huge and then reuse a 2dcontext JS object)
*[curtisk] QA contact? Talk to Juan/Matt about the QA Lead about using items in this review to build test cases
** {2011.08.19} Talked to Matt, Andrei is a contractor, they will use our notes to build test cases and get back to us to review them
 
[[Category:SecReview|AzureD2DCanvas]]

Latest revision as of 19:33, 4 January 2012

Items reviewed

Introduce Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • canvas was on cairo then cairo on top of direct2D
    • this removes cairo and replaces with Azure
  • Azure is a thinner wrapper and alows for more efficiency and better API map up
  • This is Windows only
    • For now?
    • cairo will cont on other platforms
    • & on Win where we do D2D
  • Azure is an in house developed platform
  • New implementation will be reachable directly through existing canvas functionality -- see also https://developer.mozilla.org/en/Drawing_Graphics_with_Canvas

What solutions/approaches were considered other than the proposed solution?

Why was this solution chosen?

^^ see above

Any security threats already considered in the design and why?

  • does not deal with content on websites, it's really in between
  • no specific threats considered
  • there was an info leak bug in cairo direct2D, this was taken into account bug 655836

Understanding the scope of Azure project

  • Canvas is (currently) the only place where Azure is a replacement. Elsewhere, it's in concert with existing code
  • Do we have a listing of what will using Cairo and what will using Azure (and what will using Cairo through Azure)?
  • No immediate plans to leave Cairo on nonD2D on windows, OS X will get Azure on top o core graphics, Linux will get Azure on top of Cairo
  • Fonts
    • Cairo doesn't really do fonts, freetype on Linux/OS X, and GDI on Win

Threat Brainstorming

  • Are we more worried about bugs in Azure itself, or in exposing OS APIs to attack that had previously been protected by API layers atop them (e.g. stateful or range-checking)?
    • both, right?
    • more worried about bugs in the new canvas implementation
  • Sec problems in D2D may be easier to exploit than previously as some of the layers are not there
    • Would these problems be specific to graphics cards or drivers? What kind of testing matrix do we need?
      • More likely to be bugs in D2D itself
  • Numerical thresholds?
    • Not many around pixels. Some around arcs.
    • Mostly floating point (in contrast to cairo which was mostly int), in part because D2D takes floats as input
      • The usual float concerns: NaN, Infinity, positive and negative zero, denorm, lost precision
  • Does the Azure API impose limits on the size being passed? (i.e. a very large image, larger than say the screen size)
    • No
  • What do you do when D2D returns errors?
    • Hopefully we don't draw it
    • Hopefully we don't draw uninitialized memory onto the screen
    • Hopefully we don't stop drawing the entire browser
    • Behavior here should be verified
    • D2D is restricted by texture size limits that are imposed by the graphics card
      • Normally fail if you try to create/render above limits
        • But then we fall back to a software (cairo) surface rather than giving up entirely
    • We should only get errors from D2D upon canvas creation (e.g. OOM), not upon drawing crazy shapes
      • Do we have assertions to verify this?
  • What happens when you resize a canvas?
    • Especially when you pass the size threshold while resizing?
      • And JS still has reference to a 2dcontext object?
    • Contents are lost?
  • What happens when you stretch the display of a canvas?
    • Not a big deal, basically goes through image-resize code.

Conclusions / Action Items

  • [bsterne] Fuzz canvas on top of Azure as a general fuzzing task
    • Especially radial gradients and fuzzy shadows, since those are things "done by Azure" rather than just passed to D2D
    • Is it stateless all the way down? Or does fuzzing need to take some kind of state into account?
      • Clipping is stateful. We'll often take different code paths depending on whether there's a clip or not.
    • We have a few canvas fuzzers in the private fuzzing repo
    • Do we have existing canvas tests in our test suite? Could be used for mutation fuzzing (mutate JavaScript that modifies canvas objects)
  • [jeff] bug 679868Add assertions to verify that D2D does not return errors except upon canvas creation
  • [QA?] Make sure we have regression tests for many of the questions above (e.g. what happens if you resize a canvas from tiny to huge and then reuse a 2dcontext JS object)
  • [curtisk] QA contact? Talk to Juan/Matt about the QA Lead about using items in this review to build test cases
    • {2011.08.19} Talked to Matt, Andrei is a contractor, they will use our notes to build test cases and get back to us to review them