[webkit-dev] SVG Stabilization

Maciej Stachowiak mjs at apple.com
Wed Feb 21 16:22:44 PST 2007

On Feb 21, 2007, at 8:12 AM, George Staikos wrote:

> On 20-Feb-07, at 3:13 AM, Maciej Stachowiak wrote:
>> 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
>    Have you tried using a static checker for these?

We're looking into applying a static checker for all of WebKit; we  
need to work out the logistics, to make sure there are up-to-date  
results regularly available to the community.

>> 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.
>    It's a bit worrisome that we could still have issues like this.

On the one hand, all browsers have uncaught security holes. But on  
the other hand, some of the SVG code is indeed less tested and less  
hardened than other portions of the code, which is why we are  
considering disabling some of it and want to do additional automated  
and manual testing.

I think we need to make better use of tools like fuzz testers and  
static checkers over time. With BuildBot, it's relatively simple to  
add more kinds of automated testing that happens on every checkin.


More information about the webkit-dev mailing list