[webkit-dev] SVG Stabilization

[Maciej Stachowiak]

Hi Everyone,

As part of our stabilization effort, SVG has been raised as an area  
of concern. Some of the newer SVG features have been sources of  
crashes, some of which could potentially be security issues (the ones  
that are buffer overruns).

Specifically, here are some of the risks we see from SVG in our  
current state:

* Non-security hole crashes in normal SVG content on the web - may  
affect user perception of quality, but SVG content is not yet very  
common.

* Security holes - potentially exploitable buffer overruns and such.  
These are really bad, because anyone that shipped an engine exposing  
these would be forced to issue high priority security updates as they  
get discovered. SVG content being relatively rare will not help

* Sites developing a dependency on WebKit-specific SVG bugs - we are  
not as worried about this, since there are a number of other SVG  
implementations out there, and Gecko at least has more market share.


To address these concerns, a few of us came up with a plan which I'd  
like to propose now for discussion. I would especially like to hear  
from WebKit SVG hackers on this.

1) Disable newer/experimental features   (we'd probably guard these  
with a single SVG_EXPERIMENTAL_FEATURES ifdef)
   * SVGImage -- already disabled
   * Animation -- not tested anywhere enough yet, and still noticably  
unstable
   * Filters -- still unstable, and can cause problems with buggy  
graphics drivers which take down the whole machine
   * Use -- untested/unstable
   * foreignObject -- might have issues with html inside svg,  
particularly for hit testing, etc


2) Additional testing
   * Fuzz-test for custom parsers - the biggest security risk is  
buffer overruns in some of the custom parsers, so we'd like to  
develop a fuzz-testing tool for attributes that trigger these, and  
fix resulting crashes.
   * XSS testing - SVG has many elements that reference external  
content, these should be tested for cross-site scripting risk.
   * Additional ad-hoc testing - we will need community help with this
   * Look into generating new results for pixel tests and keep them  
passing, once experimental features are off on trunk.

Thoughts?


Regards,
Maciej