I posted questions regarding character encodings considerations in XML parser implementation in the xml-dev mailing list.
See: http://lists.xml.org/archives/xml-dev/200703/msg00074.html
Showing posts with label xml parser. Show all posts
Showing posts with label xml parser. Show all posts
Thursday, March 8, 2007
Wednesday, February 14, 2007
Some of my reading for today
Wei Zhang and R. van Engelen: "A Table-Driven Streaming XML Parsing Methodology for High-Performance Web Services". ICWS '06. International Conference on Web Services, 2006. September 2006. pp 197-204
David F. Bacon. Realtime Garbage Collection. IBM Research. ACM Queue Vol 5. No. 1 - February 2007.Automata theory for XML researchers. F. Neven. ACM SIGMOD Record. Volume 31 , Issue 3 (September 2002). Pages: 39 - 46. 2002.
Bryan Ford. Packrat Parsing: a Practical Linear-Time Algorithm with Backtracking. Master's Thesis. Massachusetts Institute of Technology.
Tuesday, February 6, 2007
XML Parser attacks -- talk I gave today at the israel.pm meeting
I gave a talk today about XML Parser Attacks in the monthly meeting of israel.pm.
See: http://yeda.cs.technion.ac.il/~yona/talks/xml_parser_attacks/slides/index.html
I will probably have a few revisions on it sometime in the future.
See: http://yeda.cs.technion.ac.il/~yona/talks/xml_parser_attacks/slides/index.html
I will probably have a few revisions on it sometime in the future.
Thursday, February 1, 2007
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.
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.
Wednesday, January 31, 2007
XML processor attacks
I have posted a query to the xml-dev mailing list asking about a summary of XML parser attacks.
see: http://lists.xml.org/archives/xml-dev/200701/msg00343.html
So far I only got to hear about the "exploding entity": which is something you'd get when your XML instance contains some DTD declaration which defines entities in a recursive manner such that the final tokens that result from the definition never get recognized due to the left production nature of the definition. This results in a memory usage by the XML processor which might end up crashing it while parsing the XML instance trying to resolve the entity definition. This kind of an attack is usually being referred to as an XML Bomb.
Here's an example, extracted from Hardening Network Security, chapter 5:
<!DOCTYPE foobar [
<!ENTITY x0 "hello">
<!ENTITY x1 "&x0;&x0;">
<!ENTITY x2 "&x1;&x1;">
<!ENTITY x3 "&x2;&x2;">
<!ENTITY x4 "&x3;&x3;">
...
<!ENTITY x98 "&x97;&x97;">
<!ENTITY x99 "&x98;&x98;">
<!ENTITY x100 "&x99;&x99;">
]>
<foobar>&x100;</foobar>
A known buzzword is the XXE (Xml eXternal Entity) Attack: This is a fancy name for an attack on some application which parses XML, as part of its implementation, and is parsing XML data from some untrusted sources, which may lead to a denial of service (DoS) attack, exposure of sensitive information, or some other damage to the application or the infrastructure that it uses. This can happen, for example, when referring to some entity which is being defined as an access to some local file (e.g., some password file...). Processing of file inclusions and other attachments can be considered an XXE.
Another buzzword is XDoS: XML Denial of Service. This is a term to describe attacks on an XML parser which result in causing it to consume too much memory, slow down operations, or just work for nothing. It might also refer to cases where the DoS is on some other component of the application and the XML was the took for facilitating the attack.
Additional attacks are: signature redirects ...
see: http://lists.xml.org/archives/xml-dev/200701/msg00343.html
So far I only got to hear about the "exploding entity": which is something you'd get when your XML instance contains some DTD declaration which defines entities in a recursive manner such that the final tokens that result from the definition never get recognized due to the left production nature of the definition. This results in a memory usage by the XML processor which might end up crashing it while parsing the XML instance trying to resolve the entity definition. This kind of an attack is usually being referred to as an XML Bomb.
Here's an example, extracted from Hardening Network Security, chapter 5:
<!DOCTYPE foobar [
<!ENTITY x0 "hello">
<!ENTITY x1 "&x0;&x0;">
<!ENTITY x2 "&x1;&x1;">
<!ENTITY x3 "&x2;&x2;">
<!ENTITY x4 "&x3;&x3;">
...
<!ENTITY x98 "&x97;&x97;">
<!ENTITY x99 "&x98;&x98;">
<!ENTITY x100 "&x99;&x99;">
]>
<foobar>&x100;</foobar>
A known buzzword is the XXE (Xml eXternal Entity) Attack: This is a fancy name for an attack on some application which parses XML, as part of its implementation, and is parsing XML data from some untrusted sources, which may lead to a denial of service (DoS) attack, exposure of sensitive information, or some other damage to the application or the infrastructure that it uses. This can happen, for example, when referring to some entity which is being defined as an access to some local file (e.g., some password file...). Processing of file inclusions and other attachments can be considered an XXE.
Another buzzword is XDoS: XML Denial of Service. This is a term to describe attacks on an XML parser which result in causing it to consume too much memory, slow down operations, or just work for nothing. It might also refer to cases where the DoS is on some other component of the application and the XML was the took for facilitating the attack.
Additional attacks are: signature redirects ...
Subscribe to:
Posts (Atom)