Re: [xml] Security fix for libxml2
On Wed, Aug 20, 2008 at 07:00:51PM +0200, Daniel Veillard wrote: Bad news, when checking against recursive entities expansion problem back when it was made official (c.f. the billion laught attack circa 2004) I had checked for the normal recursion, but when happening in an attribute avlue the resource consumption is way faster and the recursion detection in place is not sufficient to catch the problem. Basically when this happen within an attribute just checking for a recursion depth is not sufficient, and the only good method I could find was to count the number of entities replacement taking place while parsing a given document, and drop parsing after half a million substitution. I think it's a fair default processand what the patches below implements for various libxml2 versions, but i can understand that in some case that may be problematic. So i intend in the next release (2.7.0 hopefully available soon) to add a parser flag removing the hardcoded limits (there is also a maximum document depth in place). Distributions have been made aware of the problem for a couple of weeks and updates should be available soon from normal update channels I'm updating SVN with the fix too, FWIW, this patch broke binary compatibility with librsvg, which, foolishly, create xmlEntity objects by hand with a malloc(sizeof(xmlEntity)), in rsvg_entity_decl, which is sets as SAX entity handler. I hope there aren't any more surprises with other libraries or programs. Mike ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Security fix for libxml2
On Sun, Aug 24, 2008 at 10:15:41AM +0200, Mike Hommey wrote: On Wed, Aug 20, 2008 at 07:00:51PM +0200, Daniel Veillard wrote: Bad news, when checking against recursive entities expansion problem back when it was made official (c.f. the billion laught attack circa 2004) I had checked for the normal recursion, but when happening in an attribute avlue the resource consumption is way faster and the recursion detection in place is not sufficient to catch the problem. Basically when this happen within an attribute just checking for a recursion depth is not sufficient, and the only good method I could find was to count the number of entities replacement taking place while parsing a given document, and drop parsing after half a million substitution. I think it's a fair default processand what the patches below implements for various libxml2 versions, but i can understand that in some case that may be problematic. So i intend in the next release (2.7.0 hopefully available soon) to add a parser flag removing the hardcoded limits (there is also a maximum document depth in place). Distributions have been made aware of the problem for a couple of weeks and updates should be available soon from normal update channels I'm updating SVN with the fix too, FWIW, this patch broke binary compatibility with librsvg, which, foolishly, create xmlEntity objects by hand with a malloc(sizeof(xmlEntity)), in rsvg_entity_decl, which is sets as SAX entity handler. Yup: http://bugzilla.gnome.org/show_bug.cgi?id=549087 https://bugzilla.redhat.com/show_bug.cgi?id=459830 I have some backward compatible patches on that last bug I hope there aren't any more surprises with other libraries or programs. yeah, it's a serious problem, I made data structure available to help with fast access to the trees, but people have abused it, I hope there isn't too many of those. I hope librsvg get fixed, because I would really prefer the clean solution in the upcoming 2.7.0 release. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [EMAIL PROTECTED] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] C14N does not handle empty-namespace declarations as the implementation in Java
Hello, I've filed the following bug-report, but Daniel Veillard told me, that it'll be best to post on the mailing list and check with Aleksey. So this is what I'll do now ;) So here's my bugreport: Please describe the problem: The Problem is the following section of the C14N Recommondation: 4.7 Propagation of Default Namespace Declaration in Document Subsets The XPath data model represents an empty default namespace with the absence of a node, not with the presence of a default namespace node having an empty value. Thus, with respect to the fact that element e3 in the following examples is not namespace qualified, we cannot tell the difference between e1 xmlns=a:be2 xmlns=e3//e2/e1 versus e1 xmlns=a:be2e3 xmlns=//e2/e1. All we know is that e3 was not namespace qualified on input, so we preserve this information on output if e2 is omitted so that e3 does not take on the default namespace qualification of e1. The implementation of C14n in libxml2 does not seem to do have the same behavior, as the implementation of Sun (for Java) or IBM (see http://www.aleksey.com/pipermail/xmlsec/2003/000976.html ), thus I do not think, this will change in the future. I'm actually not quite sure, what is meant by that part of the specification, so it might be quite possible, that Sun and IBM are correct, but libxml2 is not. Steps to reproduce: Try to canocalize the following XML-Document (I have reduced it to the essential part): dsig:SignedInfo xmlns=http://www.w3.org/2000/09/xmldsig#; xmlns:dsig=http://www.w3.org/2000/09/xmldsig#; dsig:CanonicalizationMethod Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315/ dsig:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1/dsig:Reference URI= dsig:Transforms dsig:Transform Algorithm=http://www.w3.org/TR/1999/REC-xpath-19991116;dsig:XPath xmlns:dsig=http://www.w3.org/2000/09/xmldsig#; count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) gt; count(ancestor-or-self::dsig:Signature) /dsig:XPath /dsig:Transform /dsig:Transforms dsig:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/ dsig:DigestValuenDF2V/bzRd0VE3EwShWtsBzTEDc=/dsig:DigestValue/dsig:Reference /dsig:SignedInfo Actual results: libxml2 canocalisation adds, because in SignedInfo xmlns=http://www.w3.org/2000/09/xmldsig#; is defined, loads of xmlns= declarations to all child nodes of SignedInfo and it does not remove the extra namespace declaration in XPath (as it must accoriding to http://www.w3.org/TR/2001/REC-xml-c14n-20010315#SuperfluousNSDecl ) Expected results: Java does not add the extra xmlns= and removes the extra namespace declaration in XPath. Because C14N is used for signing documents, all implementations must behave the same, else the signatures cannot be verified. So I expect libxml2 to behave as Java (and as it seems the rest of the world does) Does this happen every time? I only have tested it with this example (or slight modifications), but I checked the code and it should not behave very differently in other cases. cheers, Arne PS: I already wrote a fix that seems to work for me, but I'm not quite sure, if it's really correct. I think I actually only had one example case with that special problem to test it against. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Set Default Namespace
On 22/08/2008, Niels Van Hoef [EMAIL PROTECTED] wrote: When generating an XML document I want to set a default namespace as recommended on the namespaces page of the xmlsoft website. The function xmlNewNs only allows me to set a namespace with a prefix but not change/insert a default namespace. I may be missing the point here, but just pass NULL as the prefix to xmlNewNs? Also note, for the root element, you need to create the element, then the ns, then use xmlSetNs, see http://mail.gnome.org/archives/xml/2008-June/msg00069.html and related thread. Martin ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] C14N does not handle empty-namespace declarations as the implementation in Java
Hi, Arne! Sorry, but as I have replied in xmlsec mailing list, I believe that libxml2 is doing the right thing here. Aleksey Arne Mueller wrote: Hello, I've filed the following bug-report, but Daniel Veillard told me, that it'll be best to post on the mailing list and check with Aleksey. So this is what I'll do now ;) So here's my bugreport: Please describe the problem: The Problem is the following section of the C14N Recommondation: 4.7 Propagation of Default Namespace Declaration in Document Subsets The XPath data model represents an empty default namespace with the absence of a node, not with the presence of a default namespace node having an empty value. Thus, with respect to the fact that element e3 in the following examples is not namespace qualified, we cannot tell the difference between e1 xmlns=a:be2 xmlns=e3//e2/e1 versus e1 xmlns=a:be2e3 xmlns=//e2/e1. All we know is that e3 was not namespace qualified on input, so we preserve this information on output if e2 is omitted so that e3 does not take on the default namespace qualification of e1. The implementation of C14n in libxml2 does not seem to do have the same behavior, as the implementation of Sun (for Java) or IBM (see http://www.aleksey.com/pipermail/xmlsec/2003/000976.html ), thus I do not think, this will change in the future. I'm actually not quite sure, what is meant by that part of the specification, so it might be quite possible, that Sun and IBM are correct, but libxml2 is not. Steps to reproduce: Try to canocalize the following XML-Document (I have reduced it to the essential part): dsig:SignedInfo xmlns=http://www.w3.org/2000/09/xmldsig#; xmlns:dsig=http://www.w3.org/2000/09/xmldsig#; dsig:CanonicalizationMethod Algorithm=http://www.w3.org/TR/2001/REC-xml-c14n-20010315/ dsig:SignatureMethod Algorithm=http://www.w3.org/2000/09/xmldsig#rsa-sha1/dsig:Reference URI= dsig:Transforms dsig:Transform Algorithm=http://www.w3.org/TR/1999/REC-xpath-19991116;dsig:XPath xmlns:dsig=http://www.w3.org/2000/09/xmldsig#; count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) gt; count(ancestor-or-self::dsig:Signature) /dsig:XPath /dsig:Transform /dsig:Transforms dsig:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/ dsig:DigestValuenDF2V/bzRd0VE3EwShWtsBzTEDc=/dsig:DigestValue/dsig:Reference /dsig:SignedInfo Actual results: libxml2 canocalisation adds, because in SignedInfo xmlns=http://www.w3.org/2000/09/xmldsig#; is defined, loads of xmlns= declarations to all child nodes of SignedInfo and it does not remove the extra namespace declaration in XPath (as it must accoriding to http://www.w3.org/TR/2001/REC-xml-c14n-20010315#SuperfluousNSDecl ) Expected results: Java does not add the extra xmlns= and removes the extra namespace declaration in XPath. Because C14N is used for signing documents, all implementations must behave the same, else the signatures cannot be verified. So I expect libxml2 to behave as Java (and as it seems the rest of the world does) Does this happen every time? I only have tested it with this example (or slight modifications), but I checked the code and it should not behave very differently in other cases. cheers, Arne PS: I already wrote a fix that seems to work for me, but I'm not quite sure, if it's really correct. I think I actually only had one example case with that special problem to test it against. ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
