We bought Purim (פורים) outfits for the kids:
Aviv will dress up as a pirate.
Sivan will dress up as Snow White.
Nir will be dressed up with the kids' stuff from previous years :-)
Monday, February 5, 2007
I just submitted another patent idea to a patent committee at work
I have just sent another patent idea to the patent committee at work. The idea is about automatic detection of zero-day-attacks and automatic creation of signatures from the resulting examples.
Let's wait and see what the verdict will be...
Let's wait and see what the verdict will be...
Sunday, February 4, 2007
Swimming lessons
Lately, I'm thinking about a swimming course for Aviv. Last year he really enjoyed attending swimming classes.
As soon as the season starts, I'll check the local swimming pool for possibilities.
In the picture you can see Aviv in a swimming lesson. This picture was taken last June.
Two new recruites
Two people that I recommended for work have been found qualified and wanted to come work with us in Tel-Aviv. Hurray!
I was very impressed with them and I'm sure they will be great.
It turns out that with these two, 10% of the workers in our R&D center were recruited through me :-)
I'm trying to get at least 3 additional people in the following weeks.
I was very impressed with them and I'm sure they will be great.
It turns out that with these two, 10% of the workers in our R&D center were recruited through me :-)
I'm trying to get at least 3 additional people in the following weeks.
A discussion about my picture of the Cyclamen persicum in the photography forum in Tapuz
My photograph caused a bit of discussion.
See: http://www.tapuz.co.il/tapuzforum/main/Viewmsg.asp?forum=215&msgid=93455507
See: http://www.tapuz.co.il/tapuzforum/main/Viewmsg.asp?forum=215&msgid=93455507
Saturday, February 3, 2007
Cyclamen Persicum
Among the hundreds of bulbs that I places in many locations in our garden, I also placed 100 or so bulbs of Cyclamen Persicum. All from the "wild" kind. I bought all the bulbs from יודפת.In the picture you see the first blossom.
Anemone coronaria
There are many blossoms of Anemone coronaria in our home garden. I placed many bulbs in several locations in the garden. I placed them in layers and during a period of a few weeks.You can see in the picture some of the first blossoms.
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 ...
Subscribe to:
Posts (Atom)