[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Oh those XML Viruses


i want one oh those
From: Paul Prescod [mailto:paul@p...]

Bullard, Claude L (Len) wrote:
> ...
> 
>> 1. Why have the scanner vendors taken until now to figure this out?
>> 2. Why single out Microsoft?  

>I'm curious what other XML vocabularies you know of that transport 
>Turing-complete macros with complete access to every COM object on the 
>system?

And they are just now waking up to the fact of macros in markup? 
Seems sort of a learning curve problem if it took Office betas to 
make them realize that.  Admittedly, the COM-level integration of 
the MS Office framework opens up a lot of wholes, but show me other 
vendors with as much integration on the desktop at all.  I agree 
that MS should be, with the lionshare, a lot more sensitive to the 
problem, but I don't know if fixed positions or headers are the 
solution for the long term.   Office may be the first one with a big 
enough desktop mindshare that it rang some alarm bells, but 
is isn't a new problem.  My sense here is that MS is their market so
that is the only thing they are looking at.  It might be better to 
face up to the problem at a higher level if they want their solutions 
to work in other XML systems.

>The only one I know if is XHTML, and people expect the browser to 
>enforce its sandbox, not a virus checker.

Good question because HTML is what I had in mind, but we did it 
with the MID, X3D and VRML have scripts in them, and so 
does SVG, yes?  However, does the browser see the file if the 
mailer is getting it?  It is the mail system that would worry 
me most.

There were other markup vocabularies with scripts in them, and 
there will probably be more.  I don't think a header is the 
whole answer here. 

>> Tit:  Scanning the whole file slows us down.  
>> Tat:  Viruses take you all the way out.  

>Non sequiter. Let me try an analogous argument: "removing the steering 
>wheel from the car slows us down." "Theft takes the whole car out." 
>Well, why not just put a lock on? Efficiency and security are not 
>necessarily at odds.

Agreed, but they are trading performance for a level of consistency 
that XML can't guarantee and want one particular vendor to fix it 
without addressing the bigger issues.  If we want a truly open 
network with interoperable solutions, as noted for some time 
and many people in many places, interoperability has to start 
with the syntax then work on the applications.  Syntax doesn't 
buy us much for this particular problem.  Is there a 
general solution for XML application languages besides pulling 
the scripts out of the documents as you suggest below?

>> Tit:  Microsoft should behave as they ought.
>> Tat:  So should scanner software.  Just because 
>>       the header says the macros are "here" doesn't 
>>       mean another one isn't "there".  One might 
>>       want to validate too.

>A macro that cannot be executed by the software is harmless. It is just 
>data.

Yep, but one that can and does is dangerous regardless of where 
one puts it in the file.  The issue is bigger than Office, but 
again, failing to scan the whole file is an invitation to danger.

>> Tit:  It's Microsoft's fault.
>> Tat:  Microsoft didn't invent XML. 
>>       This is a problem for any XML that 
>>       can contain a macro and any system 
>>       that doesn't sandbox it.

>You act as if there is a long list of such systems.

See any XML application language with a script in it.  Some now, 
more later.  We had VRML viewers that weren't inside the browser, 
we have PDF viewers, and so forth.  I guess the question is one 
of how sandboxing works and is it a system-wide capability that 
any viewing app with network access can plug in to.

>> Gee.  What will Open Office do?

>It doesn't practically matter as a performance issue. The volume of data 
>flowing across the firewall in open office format will be a tiny 
>fraction of the Office data.

Please explain.

>I would hope that OpenOffice has a macro sandbox (or separates macros 
>from documents), but I don't know for sure.

Yes.  It's an old debate in markup circles.  For SGML, it was mostly 
a theoretical worry because few systems had any support for inlined 
code except the processing instructions, stylesheet code, etc; and 
validation was required, not optional.  If one doesn't validate, 
it might be a good idea to separate the macros out from documents, 
but I can hear the howling from MIT on that one.

len

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.