XML processor attacks continues

Following my blog post from yesterday about XML processor attacks, I'd like to add additional information based on a discussion which I started on the xml-dev mailing list.

David Megginson says that:

* XML REC does not specify or limits any name, literal lengths, number of attributes, depth of nested elements and so on. As a result these are a target for DoD attack on the XML processor. He suggests a few tests that can be used on an XML processor to make sure whether or not it can terminate processor prior to running out of its resources and make a graceful exit rather than crash. He states that any XML parser should have built in limitations on such properties.

* He also lists the risks in allowing processing of external fragments.

* He explains how access to an external resource, e.g., a schema or DTD, can be subject to a DoS if the location has been compromised.


derek denny-brown says that:

* a naive implementation of duplicate attribute detection or a namespace prefix lookup, e.g., using a stack implementation where the Nth string is being matched against the other N-1 strings, has an O(N^2) complexity. He also suggests that if the implementation is hash based and the attacker can guess your hashing algorithm, then the O(N^2) complexity for processing time can also be imposed on the parser.
* he also estimates that it would be quite hard to craft an attack that leverages these vulnerabilities to do much damage since the scan is extremely fast, so by limiting the size of the accepted document such attacks can be practically blocked.

Richard Salz says that:

* it should be pretty easy to cause a DoS with short messages with a very large (he gives 1 million as an example) elements depth. Another example would be badly fragmented nested elements. He further gives examples of very long element names, attribute names, namespace prefixes, and excessively long attribute or namespace declarations values.
* he states that the a-symmetrical nature gives advantage to the attacker as producing an attack is as simple as printing text while processing the received documents in such cases yields expensive computation.



I'm still collecting material and organizing it, and I hope that I will be able in the next few days to write a detailed and more organized summary on the subject. I'll post it here on my blog and will probably also announce its availability on xml-dev at least to be polite and write back my conclusions and contributions to the discussion.