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

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