[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Oh those XML Viruses
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|