Fwd: [xml-dev] XML processor attacks

["David Megginson" <david.megginson@gmail.com>]

Oops -- this should have gone to the whole list.  I find the choice of
reply-to sender instead of list for xml-dev rather annoying.

---------- Forwarded message ----------
From: David Megginson <david.megginson@gmail.com>
Date: 31-Jan-2007 08:41
Subject: Re: [xml-dev] XML processor attacks
To: Shlomo Yona <S.Yona@f5.com>


On 30/01/07, Shlomo Yona <S.Yona@f5.com> wrote:

> I've been googling a lot and was unable to find a summary of XML
> processor attacks.

The first risk is that the XML REC places no limits at all on name
lengths, literal lengths, number of attributes, depth of nested
elements, etc.  So to test a processor, the best place to start is to
create documents with extreme examples of each; for example, you can a
Perl script that simply feeds "<x><x><x>" repeating through a pipeline
to a processor to see what it does once the elements are nested, say,
10^12 levels deep.  Write another script that creates an element,
entity, or attribute with a 10GB name, or a 10GB attribute value
literal.  Try '<x a1="y" a2="y" a3="y"' and so on, to see what a
couple of million attributes will do.  Test what happens when an
entity refers to itself.  etc.  Any parser that doesn't eventually
report a resource error and die gracefully in these situations
probably isn't robust enough for production use.  This implies that
every parser should have some kind of very generous built-in limit for
these things (say, 1024 characters for a name, 1,000,000 characters
for an attribute value literal, maximum 4096 levels of element
nesting, etc.).

The next level stage these simple DOS or buffer-overflow attacks is
the risk of including external fragments, either entities, external
DTD subsets, or schemas.  In all of these cases, if the system hosting
the external fragment is compromised or unavailable, bad things can
potentially happen -- for example, if you have

<!DOCTYPE foo SYSTEM "http://www.example.org/foo.dtd";>

at the top of all your XML documents, many validating processors will
fail if foo.dtd goes offline.  If someone compromises example.org,
they can edit foo.dtd to add default attribute values (etc.) to change
the meaning of your XML document.


All the best,


David