Re: [ACTION-412][Fwd: Re: namespace wrapping attacks against XML Signature?]

We should add the following explanation, with some editing, to the 2.0  
requirements on prefix rewriting , agreed?

[[
After all, having the namespace prefixes covered by the signature  
actually is some kind of violation of the idea of prefixes. As far as  
I understood that concept, the prefixes don't have to be unique, and  
may even be substituted within any processing instant if two prefixes  
happen to cause a collision. The only requiredly unique setting is the  
namespace uri and local name. Thus, if the (unlikely, agreed) case  
happens that two XML documents are to be merged that both have the  
same namespace prefix for different namespace uris, whereas XML  
Signatures protect the chosen prefixes in both documents, you either  
have to invalidate one of the signatures (by changing its prefixes) or  
risk a processing collision (by keeping the same namespace prefix for  
different uris).
]]


regards, Frederick

Frederick Hirsch
Nokia



On Dec 8, 2009, at 3:41 AM, ext Meiko Jensen wrote:

> Hi Pratik, all,
>
> see inline.
>
> Pratik Datta schrieb:
>>
>> I read the paper, very interesting.
>>
> Thanks :)
>> The crux of the attack is that the XPath expression is considered a  
>> text node, so Exclusive Canonicalization does not consider any of  
>> the namespaces prefixes inside that as visibly utilized, hence it  
>> doesn't include them.
>>
> Exactly. And obviously, if c14n is omitted completely, the attack  
> vector is even larger.
>> Apart from the three solutions mentioned in the paper, there is  
>> another one. Some XML signature libraries (e.g. Oracle's) provide  
>> an API to resolve the references of signature. This API takes in  
>> signature and returns all the DOM nodes , subtrees, binary objects  
>> etc that are included in this signature. I.e. in this example it  
>> will return the DOM node for the attack wsa:Reply element. The  
>> calling application can now compare this DOM node with the DOM node  
>> of the expected wsa:Reply element. DOM provides an isSameNode API (http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-isSameNode 
>> ) to check if two DOM nodes are the same.
>>
> This implies the "see-what-is-signed" approach: the application  
> logic can only "see" (=process) those DOM nodes that are covered by  
> the signature. That approach fends about all kinds of Signature  
> Wrapping, agreed, but has some drawbacks. First one is that the  
> application logic can no longer see the unsigned data, which may  
> cause every kind of interoperability problems. Further, the signed  
> contents do not have to form a DOM tree of its own; they e.g. may  
> have several root nodes. Finally, this approach requires signature  
> validation and application logic to reside on the very same system  
> in order to run the identity test. This is not a viable approach for  
> every scenario (e.g. consider the common case of a WS-Security  
> gateway at a company's network border and a set of separate  
> application servers within the network.).
>> In XML Signature 2.0, we have separated the Selection and  
>> Canonicalization, to deal with these kinds of wrapping attacks. XML  
>> Signature 2.0 libraries should be able to evaluate the Selection  
>> part only and return the exact list of "things" that are included  
>> in the Signature.
>>
> I actually yet didn't investigate 2.0 for this, but I'd assume the  
> issue not to be solved that easily. For the scenario described  
> above, any kind of signature validation must adapt to the  
> application logic or vice versa in order to eliminate the threat.  
> I'm not sure this can be done by changing the selection in XML  
> Signature only. But maybe I'm wrong....
>> Canonicalization 2.0 defines a namespace prefix rewriting option  
>> with sequential prefixes. This is very similar to the "Prefix Free  
>> Canonicalization" proposed in this paper.
>>
> Definitely makes sense to me. After all, having the namespace  
> prefixes covered by the signature actually is some kind of violation  
> of the idea of prefixes. As far as I understood that concept, the  
> prefixes don't have to be unique, and may even be substituted within  
> any processing instant if two prefixes happen to cause a collision.  
> The only requiredly unique setting is the namespace uri and local  
> name. Thus, if the (unlikely, agreed) case happens that two XML  
> documents are to be merged that both have the same namespace prefix  
> for different namespace uris, whereas XML Signatures protect the  
> chosen prefixes in both documents, you either have to invalidate one  
> of the signatures (by changing its prefixes) or risk a processing  
> collision (by keeping the same namespace prefix for different uris).  
> Thus, if you already are in the process of redefining  
> canonicalization, I'd recommend to take this issue into  
> consideration. Maybe there's no real-world scenario for this, but if  
> there is, it would cause a counterexample showing the standard's  
> discrepancies.
>> Canonicalization 2.0 also looks at some prefixes that are embedded  
>> in content. Currently it only looks at prefixes in xsi:type  
>> attribute. We might consider extending it to prefixes in the  
>> IncludedXPath and ExcludedXPath elements.
>>
> The issue here is that you'd have to identify all text nodes that  
> may contain XPath expressions, and perform some kind of "prefix  
> search" (not only string search for e.g. "ns1:", this may also find  
> string literals in XPath) on them. On the other hand, for "normal"  
> text nodes you MUST NOT perform this search, as this would cause  
> weird namespace inclusions "by accident" (think of having a "CC:"  
> mail header in a text node, and CC being among the defined namespace  
> prefixes). Either way, this again is a perfect source for "getting  
> it wrong" on implementation and causing signature interoperability  
> issues. But I have to admit by now I don't see a better solution  
> here (apart from the ones in the paper or using something else  
> rather than full XPath or IDs).
>
> If I can make it, I'll check out 2.0 asap.
>
> cheers
>
> Meiko
>> Pratik
>>
>>
>>
>>
>> -----Original Message-----
>> From: Ed Simon [mailto:edsimon@xmlsec.com]
>> Sent: Tuesday, December 01, 2009 1:09 PM
>> To: XMLSec WG Public List
>> Cc: Meiko Jensen; Jörg Schwenk
>> Subject: [ACTION-412][Fwd: Re: namespace wrapping attacks against  
>> XML Signature?]
>>
>> The attached paper (attached with permission of its authors)  
>> describes in detail the attack vector described in my 2009 April  
>> [1] post and subsequent discussions (looks like we independently  
>> became concerned about the same issue). Please review it so that we  
>> discuss whether there is general agreement that we need to address  
>> it.
>>
>> Thanks,
>> Ed
>>
>> [1] http://lists.w3.org/Archives/Public/public-xmlsec/2009Apr/0025.html
>>
>> -------- Forwarded Message --------
>> From: Meiko Jensen <Meiko.Jensen@ruhr-uni-bochum.de>
>> To: edsimon@xmlsec.com, Meiko Jensen <Meiko.Jensen@rub.de>, Jörg  
>> Schwenk <joerg.schwenk@rub.de>, 'Thomas Roessler' <tlr@w3.org>,  
>> 'Frederick Hirsch' <Frederick.Hirsch@nokia.com>
>> Subject: Re: namespace wrapping attacks against XML Signature?
>> Date: Tue, 24 Nov 2009 10:51:42 +0100 (CET)
>>
>> Hi Ed, see below...
>>
>> Ed Simon schrieb am 2009-11-23:
>>
>>> Thanks Meiko,
>>>
>>
>> ...
>>
>>
>>> Is the W3C allowed to post your paper to the W3C public archive  
>>> list?
>>>
>>
>> Feel free to do so :)
>>
>> best regards from Bochum, Germany
>>
>> Meiko
>>
>>
>>> Regards,
>>> Ed
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> ========================================
>> Ed Simon
>> 613-726-9645
>> edsimon@xmlsec.com
>>
>
>
> -- 
> Dipl.-Inf. Meiko Jensen
> Chair for Network and Data Security
> Horst Görtz Institute for IT-Security
> Ruhr University Bochum, Germany
> _____________________________
> Universitätsstr. 150, Geb. IC 4/150
> D-44780 Bochum, Germany
> Phone: +49 (0) 234 / 32-26796
> Telefax: +49 (0) 234 / 32-14347
> http:// www.nds.rub.de

Received on Tuesday, 29 December 2009 20:19:06 UTC