Here's a mushroom I shot this morning at dawn in a field just next to our home.
Friday, February 2, 2007
Dawn in Kfar-Yona
I went today a few minutes before dawn to setup my camera and take a few shots.
While today was clear, since this evening it begun to get more and more gray and rainy. Tomorrow is expected to be accompanied by heavy rains.
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 ...
Monday, January 29, 2007
So, you want to implement an XML Schema Processor?
I was recently asked to look into the design and later on the implementation of XML processors that are able to do XML parsing, XML Schema validation, XPath/XQuery queries, WSDL and SOAP analysis and enforcement, and much much more.
When one is required to implement a tool which implements complex and detailed standards, which rely on other complex standards, especially when short in time, one seeks to classify the features into two main categories: "frequently used" and "rarely used". The motivation for this classification is that "frequently used" features get to be considered and implemented first while the "rarely used" ones get time and attention later on.
Starting with XML Schema (of course with the aid of the very useful book Definitive XML Schema), I was faced with the need to perform such categorization. Not having enough time to properly read the standard throughout, read commentary about it in mailing lists such as the xml-dev mailing list, and complement the knowledge with explanations from books and of course from actual practice (examining freely available XML Schemas for example), I was forces to an ad-hoc approach.
I browsed the web for some available summary on XML Schema, hopefully, including the above mentioned categorization. To my happiness, I was successful. I came across the article Profiling XML Schema by by Paul Kiel, which was published on xml.com on September 20th, 2006.
My short term approach will be to try and confirm the results and conclusions that were presented in this article with several examples of WSDLs and XML Schemas available on the wild (e.g., Google's XML based interfaces for its services).
Let's see how it goes.
When one is required to implement a tool which implements complex and detailed standards, which rely on other complex standards, especially when short in time, one seeks to classify the features into two main categories: "frequently used" and "rarely used". The motivation for this classification is that "frequently used" features get to be considered and implemented first while the "rarely used" ones get time and attention later on.
Starting with XML Schema (of course with the aid of the very useful book Definitive XML Schema), I was faced with the need to perform such categorization. Not having enough time to properly read the standard throughout, read commentary about it in mailing lists such as the xml-dev mailing list, and complement the knowledge with explanations from books and of course from actual practice (examining freely available XML Schemas for example), I was forces to an ad-hoc approach.
I browsed the web for some available summary on XML Schema, hopefully, including the above mentioned categorization. To my happiness, I was successful. I came across the article Profiling XML Schema by by Paul Kiel, which was published on xml.com on September 20th, 2006.
My short term approach will be to try and confirm the results and conclusions that were presented in this article with several examples of WSDLs and XML Schemas available on the wild (e.g., Google's XML based interfaces for its services).
Let's see how it goes.
Saturday, January 27, 2007
I made it to the final in תחרות הפאדיחה
Apparently, my story made it to the final stage in the פאדיחה contest in Tapuz.
See: http://www.tapuz.co.il/tapuzforum/main/Viewmsg.asp?forum=149&msgid=93059365
See: http://www.tapuz.co.il/tapuzforum/main/Viewmsg.asp?forum=149&msgid=93059365
Winter puddle/swamp in Netaniya
We drove to Netaniya's Winter puddle/swamp.
It is a nice area with Eucalyptus trees which, during rain season, becomes swampy.
There are ducks there, some parrots, some crows, and very nice wild flowers. Next to it there are several amusement facilities where the kids can play. We had fun.
See what I wrote about the place and about out good time there on a forum in Tapuz: חוויות בשלולית החורף כפי שפורסם בפורום הורים בתפוז
See pictures at: http://yeda.cs.technion.ac.il/~yona/aviv/2007/1.2007/
Friday, January 26, 2007
Perl::Critic static code for Perl based on Perl Best Practices
Check out the Perl::Critic module.
It claims to do "Critique Perl source code for best-practices ".
The best-practices are a-la Damian Conway's book "Perl Best Practices"
There's also a web service at: http://perlcritic.com/
It claims to do "Critique Perl source code for best-practices ".
The best-practices are a-la Damian Conway's book "Perl Best Practices"
There's also a web service at: http://perlcritic.com/
FireBug for FireFox
There's a nice addon/plugin for FireFox called FireBug, which can be used in order to get a nice view on the source of the current page that you're viewing, including HTML, CSS, JS, network statistics, including debugging, and a few more features.
See: http://www.getfirebug.com/
See: http://www.getfirebug.com/
Thursday, January 25, 2007
Added a new book review on Amazon
I just finished writing a book review to Definitive XML Schema by Priscilla Walmsley.
You can read it along with other reviews I wrote at: http://www.amazon.com/gp/pdp/profile/A10UA4V0Z4691N
You can read it along with other reviews I wrote at: http://www.amazon.com/gp/pdp/profile/A10UA4V0Z4691N
NIST announces competition for new cryptographic hash algorithm
NIST announces competition for new cryptographic hash algorithm. This sounds like a nice opportunity to go public with ideas you have for a new cryptographic hash function.
See: http://www.networkworld.com/news/2007/012307-nist-cryptographic-algorithm.html
See: http://www.networkworld.com/news/2007/012307-nist-cryptographic-algorithm.html
A nice introduction to Finite-State Automata and Regular Expression with Critique about Regular Expression Engines' implementations
Russ Cox explains and demonstrates how good old theory put to practice results in good computer programs while ignoring good theory leads to bad programs.
See: Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, ...) by Russ Cox
His regexp page contains more interesting information and implementations.
See: Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, ...) by Russ Cox
His regexp page contains more interesting information and implementations.
Subscribe to:
Posts (Atom)