[Clipart] Malware in clipart

[Bryce Harrington]

On Mon, Mar 14, 2005 at 09:37:00AM -0500, Jonadab the Unsightly One wrote:
> Andrew Archibald <andrew.archibald at sympatico.ca> writes:
> 
> > Hi,
> >
> > SVG can contain scripts, 
> 
> It can?
> 
> I didn't know that...  

XML in general permits melding of different XML syntaxes.  This is why
we can fold RDF into SVG.  Similarly, ECMA (Javascript), and other
scripting languages can be merged in (given the appropriate namespace
declarations, etc.)  E.g., for purposes of having Javascript in XHTML.
Whether a given client actually uses that data is up to the client.

The principle use for allowing ECMA in SVG is for doing a certain class
of animations.  Another is for those silly transition effects in
presentations.  I'd hesistate to say these are _good_ reasons for having
scripting, but I can understand why someone would think they were
important.

In fact, in Inkscape we've had a number of requests for adding support,
and one developer (Ishmal) has been actively working on implementing
it.

> > I know perfectly well that none of the usual applications that will be
> > used with OpenClipart currently support scripting. 
> 
> Good.  Let's hope it stays that way.  I'm a pretty imaginative guy,
> but off the top of my head I can't think of any valid reason for a
> clip art image to contain scripts.

Inkscape will be supporting scripting at some point in the future, so
figuring out a procedure for handling them now would be of value.

I also can't think of reasons why clip art should contain scripts,
however I recall we have received at least one such submission - a chess
board with Javascript program to implement playing chess.

> > But there are applications that do, and it's a problem if a user
> > gets bitten by running one of them on an openclipart image; it's a
> > much worse problem if a user gets bitten by using one to look at a
> > document containing an openclipart image. (Consider the following: I
> > make an SVG company logo that includes a piece of
> > openclipart. Someone looks at my company logo and it wipes their
> > hard drive.)
> 
> It seems to me that we will not have the resources to hand-examine
> every submission to ensure it is innocuous, so (barring an
> earthshattering breakthrough in AI research) if we take any
> precautions at all it will have to be stripping out all scripts of any
> kind, malware or not.  (Which, on the whole, doesn't sound like a
> terribly bad idea to me...  feel free to jump in and explain why we
> shouldn't do that, if you can think of any solid reasons.)

Another approach could be to simply slap a keyword on it, e.g. 'script'
or 'executable', and exclude all such images from the releases.  Then,
if people are so motivated, they can individually review/approve them.

There's four reasons for this suggestion:

First, presumably if an SVG includes a non-malware script, it's probably
there for a reason, such as for animation.  In this case, removing the
script may invalidate the image, in which case a "stripped" version
could be worthless anyway.

Second, if someone goes to the trouble of writing a script AND
submitting it to OCAL, and then the script gets stripped out, my guess
is that they're going to come and complain.  Having a procedure that
allows you to review/approve individual images on a case-by-case basis
will enable the project to handle these situations professionally, and
not as "special exceptions".

Third, this approach remains consistent with the process for handling
other types of abusive images, so hopefully would reduce the variety of
scripts needed to be written/maintained.

Finally, if in fact a given SVG image also has a piece of malware
scripted into it, how likely are we going to want to keep the image
portion?  Stripping the viral part of an email virus wouldn't turn it
into a useful email.  ;-)  I wouldn't think stripping malware from SVG
would result in a worthwhile SVG image, either.

> > does inkscape follow external references? 
> 
> That I don't know.  Bryce might.

Only for embedded images, and only to the local file system.  Both of
these are likely to change in the mid to long term though.

> Of course, we would need a sanitizer tool...  my SVG foo is not good
> enough at this time to write one of those, at least, not with any
> degree of confidence.

Again, I think instead of stripping, just flag the images and filter
them out for the releases.  This should be a simpler thing to do, and
requires only small tweaks to the existing tools, plus a simple script
to scan the SVG for keywords ("<SCRIPT...", etc.) and if it comes up
positive, move those files aside, and/or add a keyword to them.  Then,
in the release scripts, add another filter like the one for the flags,
to exclude images with scripts in them.

Bryce