Security/Reviews/Firefox7/ReviewNotes/AzureD2DCanvas
From MozillaWiki
Contents
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
- Would these problems be specific to graphics cards or drivers? What kind of testing matrix do we need?
- 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
- Normally fail if you try to create/render above limits
- 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?
- Especially when you pass the size threshold while resizing?
- 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