Comments on Connecting SOA to the Cloud: An old XML attack resurfaces, and is blocked

Hi Ari, Can you be more specific. You say "a...

2009-08-12T13:40:50.791+01:00

Hi Ari,

Can you be more specific. You say "as far as I know this is completely different from both recursions and external entities". But the first reference on the CERT-FI article relates to recursion ("Avoid recursion when parsing simply nested DTD structures").

The other references in that CERT-FI article mention DTD-based vulnerabilities.

DTD's in general are bad news for security. That is why the SOAP Spec disallows DTD's ((http://www.w3.org/TR/SOAP/ Section 3), why Microsoft created that "ProhibitDtd" option (http://support.microsoft.com/default.aspx?kbid=826231). I notice that you don't list .NET's parser as vulnerable - is that because you had "ProhibitDtd" enabled?

If you can provide an example of an XML message which brings down a parser, I'd be happy to test it here to see how the message is blocked. Vordel's standard XML Threat policy blocks DTD's, as well as excessive nesting, excessive child attributes or element "width", amongst other countermeasures like limiting memory usage for parsing.

Without an actual example, it's hard to really be specific though.

Your article mentions code execution - were you able to smash the stack of an XML parser and manipulate the execution address to point to arbitrary code? If so, what parser, and can you provide an example?

Thanks Mark for the clarification. Unfortunately ...

2009-08-12T10:06:13.893+01:00

Thanks Mark for the clarification.

Unfortunately I cannot discuss the details (and neither probably will anyone else at this point because these parsers are everywhere and almost nobody is patched against these and similar issues) but as far as I know this is completely different from both recursions and external entities. There are hundreds of thousands of ways you can suck at DTD (and other XML element) parsing. ;)

Hi Ari, The reason why this announcement is assoc...

2009-08-12T09:31:35.000+01:00

Hi Ari,

The reason why this announcement is associated with DTD-based attacks is that the CERT-FI release about it (http://www.cert.fi/en/reports/2009/vulnerability2009085.html) references a couple of DTD-based advisories like this apache revision posting:

"Avoid recursion when parsing simply nested DTD structures.
This issue is referenced in the following document: CVE-2009-1885 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1885).
Thanks to Jukka Taimisto, Tero Rontti and Rauli Kaksonen from the CROSS project at Codenomicon Ltd. and CERT-FI for bringing this issue to our attention."
http://svn.apache.org/viewvc?view=rev&revision=781488

Also the CERT-FI announcement references this Red Hat posting:

"libxml is a library for parsing and manipulating XML files. A Document Type
Definition (DTD) defines the legal syntax (and also which elements can be
used) for certain types of files, such as XML files.

A stack overflow flaw was found in the way libxml processes the root XML
document element definition in a DTD. A remote attacker could provide a
specially-crafted XML file, which once opened by a local, unsuspecting
user, would lead to denial of service (application crash). (CVE-2009-2414)"
https://rhn.redhat.com/errata/RHSA-2009-1206.html

That's why this announcement is associated with DTD-based attacks.

I took a look at your link to the announcement on your corporate site again, but it's short on specifics (like examples of messages which will bring down particular parsers, names and versions of particular parsers, etc). The only concrete info is the CERT-FI article which references the DTD attacks. It would be helpful to provide some more detail.

By the way, I do agree that the XML parsers used in XML-processing applications have vulnerabilities, (e.g. External Entity attacks). I've seen these myself - it is frightening how vulnerable many XML apps are to these. It is good to highlight people to this fact.

Oh and Hi Mark! If you write a nice new writeup ...

2009-08-12T06:01:59.736+01:00

Oh and Hi Mark!

If you write a nice new writeup of the 2002 flaw, we are happy to link to it from our XML resource here. I have seen that several people have already confused this set of problems with the 2002 flaw already.

Sorry for the typo in Vordel product name. ;)

Sorry, this has nothing to do with the 2002 attack...

2009-08-12T05:52:36.883+01:00

Sorry, this has nothing to do with the 2002 attack. And as far as I know, the Vortel test solution does not catch any of the several flaws in question.