[Clipart] Malware in clipart

[Jon Phillips]

On Mon, 2005-03-14 at 10:52 -0800, Bryce Harrington wrote:
> 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.

Yes, I agree with this approach. I'm adding to the roadmap. Does anyone
want to conquer this task? Andrew, would you like to conquer this one?
We should figure out how to add this to validation of SVG files once
input into the site and then again when doing a release. We should
discuss this further? Any specific suggestions from anyone on
implementation.

Please check roadmap: http://www.openclipart.org/cgi-bin/wiki.pl?Roadmap

We are in need of some good soldiers to help with these tasks.

Jon



-- 
Jon Phillips <jon at rejon.org>