On Fri, Feb 25, 2005 at 12:57:37PM +0000, Philip Nye wrote:
> > Virus authors need software which are in widespread use to propagate
> > their viruses. And XXE is not ( yet ;-) ) famous enough for this to happen.
>
> There is also the fact that Word macros are embedded in the documents
> which people edit and exchange. XXE macros are part of a config file
> and are not embedded in the normal XML files people are editing. This
> doesn't mean its impossible, but certainly a lot less easy.
That's right; Word macros provide an avenue for malicious entities to
inject code into a system. Two such avenues, in general, are through
system vulnerabilities and through side effects. Macro viruses would be
an example of the latter. Side effect functionality ought to be treated
with extreme prejudice in any software, including the XMLmind XML Editor
(XXE).
A side effect route is functionality provided by a given application in
addition to, or in support of, the primary functionality of that
application. For example, the automatic opening of email attachments,
the automatic installation of scripts in a web browser at a website's
request, and macros are each side effect features. They are usually
transparent to the user (i.e. automatic and non-interactive) and
sufficiently powerful to be turned against that user if the carrier of
the particular malicious side effect is untrusted.
I think it's worth considering the current potential for side effect
functionality in XXE. Note that this is likely not comprehensive.
First, XML documents themselves are clearly expressive enough to contain
code. As far as I know, XXE does not execute any of the XML that it
opens. There is no way to send an XXE user an XXE configuration and
cause them to automatically use that configuration, is there? From
here, we move on to resources that may be explicitly or implicitly
referenced and thus used when XXE opens a given document.
XXE supports callouts to stylesheets (only CSS at this time) and RELAX
NG schemata. CSS stylesheets are not expressive enough to perform
malicious behavior, right? Well, that all depends what one means by
"malicious". CSS can be used to (surreptitiously) hide or modify the
presentation of information contained in an XML document. This might be
considered malicious, although it only applies to the document sent by
the untrusted entity. I also wonder about the potential for danger with
Java CSS extensions. I don't know much about their use, though, so any
comments about their danger would be pure speculation. If XXE ever
supported XSL stylesheets, such functionality could be used to much more
potent effect, as unconstrained XSL stylesheets are expressed using a
fully functional (i.e. Turing complete) programming language that can
interface with the environment.
It might be tempting to add full support for the XML Catalog referencing
processing instructions in documents, as described in the XML Catalog
specification[0]. Note that everything here is imaginary for the time
being, although possibly instructive. If such support were added to
XXE, this could become a particularly insidious side effect avenue. XML
Catalogs allow you to change the resolution of names, which is very
useful and potentially dangerous. For example, one could change the
(local or global) URI for the DocBook XSL stylesheets to one under the
untrusted entity's control; these "new" DocBook XSL stylesheets could
behave exactly like the "real" ones, but have additional functionality.
As mentioned above, the XSL transformation language is sufficiently
powerful enough to make this quite dangerous.
Of course, as Hussein pointed out, XXE isn't yet widespread enough to
encourage the network effects of common malware. As it stands right
now, it would appear that XML documents, when processed by XXE, are
fairly inert. It never hurts to think ahead, though, and there may be a
desire to make them more dynamic in the future; such functionality can
be truly useful. XXE, as with any software, would be well advised to
disable side effect routes by default and generally step carefully.
Take care,
John L. Clark
[0] http://www.oasis-open.org/committees/entity/spec.html#oasis-er-tc-abc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://www.xmlmind.com/pipermail/xmleditor-support/attachments/20050225/c63b75c7/attachment.sig
