- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Wed, 22 Oct 2014 17:38:21 -0400
- To: public-xmlsec@w3.org
- CC: David Solin <david@joval.org>
Forwarding this inquiry to the group: -------- Forwarded Message -------- Subject: Fwd: Re: Fwd: Re: [scap-dev] Broken XML signatures in USGCB datastreams Date: Wed, 22 Oct 2014 08:09:24 -0500 From: David Solin <david@joval.org> Organization: jOVAL To: wseltzer@w3.org CC: Booth, Harold <harold.booth@nist.gov> Hello Wendy, I understand you're the W3C team contact for the Web Security Interest Group. I'd like to bring to the group's attention an issue with XML digital signature validation -- whether (and how) c14n11 applies when only an XSD is available, and if not, whether c14n11 is suitable for use with XML digital signatures in such a case. The issue arises because of a set of signed XML documents created by NIST, whose XSD specifies fixed attributes which were not added during canonicalization -- breaking the signature when it's verified using an XSD-validating parser (which is the best practice in the Java programming language). I am hoping to get an authoritative determination on the correct behavior in this case! Best regards, --David Solin -------- Original Message -------- Subject: Re: Fwd: Re: [scap-dev] Broken XML signatures in USGCB datastreams Date: Wed, 22 Oct 2014 07:59:32 -0500 From: Paul Grosso <paul@paulgrosso.name> To: David Solin <david@joval.org> CC: Booth, Harold <harold.booth@nist.gov> David, The XML Security Working Group's charter ended over a year ago, so I gather it is no longer meeting. Its chair was Frederick Hirsch <frederick.hirsch@nokia.com <mailto:frederick.hirsch@nokia.com>> and its W3C staff contact was Thomas Roessler <mailto:tlr@w3.org> <tlr@w3.org>, both of whom are still involved in Web Security and either of whom might be of more help. Currently, there is also a Web Security Interest Group (see http://www.w3.org/Security/wiki/IG) that "serves as a forum for discussion about improving standards and implementations to advance the security of the Web." Wendy Seltzer <wseltzer@w3.org> is the W3C team contact. paul On 2014-10-21 21:52, David Solin wrote: > Greetings Paul, > > I'm writing to ask you if you can direct me to the appropriate working > group or authority who can help to arbitrate on the matter below, > relating to XML digital signature verification, and the proper > behavior of the validating parser referred to by the W3C document on > XML canonicalization: > http://www.w3.org/TR/xml-c14n11/ > > Best regards, > --David Solin > > > -------- Original Message -------- > Subject: Re: [scap-dev] Broken XML signatures in USGCB datastreams > Date: Tue, 21 Oct 2014 21:49:18 -0500 > From: David Solin <david@joval.org> > Organization: jOVAL > To: Booth, Harold <harold.booth@nist.gov> > > > > Hi Harold, > > If there is no schema-validation going on, then there is no way for > the parser to know which nodes are actually IDs for the purpose of > signature validation (type=xsd:ID) -- hence making the parser > susceptible to a wrapping attack. And, with schema validation turned > on, Java's built-in DOM parser adds the fixed attributes -- which > breaks the signature validation (since the signatures were computed > without the fixed attributes in the XML). > > (I think it is obvious that adding fixed attributed during > canonicalization is the correct thing to do, provided there is > schema-awareness.) > > So, based on your assertions, where there is an XSD schema wherein > there are any fixed attributes defined: > 1) Oracle broke all out-of-the-box interoperable XML digital signature > validation (with other languages) in Java 1.7.0u25, and > 2) All versions of Java prior to 1.7.0u25 can only be used to perform > signature validation while operating in a way that is susceptible to a > wrapping attack > > Furthermore, by asserting that one cannot use a schema-validating > parser for the purposes of c14n11 in the context of XML signature > validation, you are in turn saying that the specifications dictate > that the only way to perform XML digital signature validation without > being susceptible to a wrapping attack, where only an XSD is > available, is to hand-craft validation logic that understands exactly > which element attributes are type xsd:ID. > > Do you agree that is what you're saying? Because, if you haven't > caught on, I think that is unworkable. > > In the meantime, I haven't gotten any kind of response from John Boyer > (who authored the c14n11 specification). I believe this matter must be > brought before a W3C authority, because one of the following > statements must be true: > 1) Your interpretation is wrong, or > 2) Someone in authority needs to explain to Oracle that the most > widely-used programming language for Web/XML development has a > critical interoperability flaw with respect to XMLDSIG, which should > be addressed urgently. > > I freely admit that it could be either one, and you and I are > obviously at an impasse. > > I would point out that, if NIST's XML signing process added the fixed > attributes to the canonicalized XML during signing (which would be a > perfectly valid thing to do), then both Java and whatever tools you're > already using would be able to successfully verify the signature. > > Regards, > --David Solin > > On 10/21/2014 8:53 PM, Booth, Harold wrote: >> >> I am going to start with the last point first since I think agreement >> on this point will be necessary in order to come to an agreement for >> the other points. >> >> When canonicalization occurs according to the “Canonical XML Version >> 1.1” [1] recommendation there is only the DTD and Schema is not >> processed. My reading of the recommendation is that a document which >> is described only by Schema would be treated like any other document >> without a DTD and to perform any processing based on the Schema would >> be an error. This interpretation is bolstered by a statement from >> Section 1.1 of [2] which was developed specifically to address >> limitations of [1]: >> >> “The presence of a DTD that validates the XML subdocument being >> canonicalized is assumed. In particular, default attributes specified >> in the DTD are included in the output of the canonicalization process.” >> >> The canonicalization method described in [2], which is intended to be >> Schema centric, does not appear to be implemented in widely available >> libraries; making it an impractical option. And to address the >> question posed, there is no DTD for the SCAP datastream, only Schema. >> Given there is no DTD, then any attributes added as part of a >> canonicalization of an SCAP datastream according to [1] prior to >> signing would not be interoperable. >> >> Returning to how to use the library which implements all of this, >> schema validation would certainly be an acceptable answer as long as >> it does not modify the input stream provided into the >> canonicalization. Is this the case for the methodology you are using? >> Even if the library you are using does change the input stream in >> some non-standard way, validating that an XML document conforms to >> its schema definition should certainly be done. Preferably prior to >> any signature verification, but to follow the recommendations the >> output from the validation must not be used as input into the >> canonicalization if a non-standard modification is made during the >> XML Schema validation. >> >> Protecting against a signature wrapping attack basically comes down >> to using only the content which has been signed. One mechanism is for >> the library to return the signed nodes back to the application and >> the application should only use this version of the document and not >> the original one. Another strategy, which options 2 and 3 use, is for >> the application to register the nodes which are called out by Id and >> are needed as part of the signature. The assumption is that the >> application will use the exact same nodes for processing if the >> signature verification is successful since the application already >> knows which nodes were used. And certainly a naïve implementation >> could create a wrapping vulnerability as well, but that is still an >> implementation issue for an application verifying a signature and not >> a security issue with how the content has been signed. >> >> Regards, >> >> -Harold >> >> [1] http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/ >> >> [2] http://www.uddi.org/pubs/SchemaCentricCanonicalization.htm >> >> *From:*scap-dev-bounces@nist.gov <mailto:scap-dev-bounces@nist.gov> >> [mailto:scap-dev-bounces@nist.gov] *On Behalf Of *David Solin >> *Sent:* Friday, October 17, 2014 9:48 AM >> *To:* SCAP-DEV >> *Subject:* Re: [scap-dev] Broken XML signatures in USGCB datastreams >> >> Hi Harold, >> >> I agree with your analysis about the nature of the wrapping >> vulnerability. However most XMLDSIG validation implementations will >> simply validate the signed elements of a document and proclaim the >> content to be OK, because with such an approach there is no need for >> user interaction. Such a methodology is certainly susceptible to the >> wrapping attack -- which becomes impossible if you simply turn on >> schema-validation. Validation is the simplest fix. >> >> Work-arounds 2 and 3 are less ideal, essentially amounting to >> roll-your-own-schema-validation, but only for the ID elements. The >> simplest way to implement one of these two work-arounds would >> re-create the wrapping vulnerability -- probably not what anyone had >> in mind, but a real possibility for a programmer who doesn't fully >> understand the problem. >> >> Now, the issue with signature-validating the NIST content is that the >> fixed attributes, which are omitted in the content that has been >> signed, are added when the content is parsed with schema-validation. >> The canonicalized XML therefore ends up being different -- meaning >> the checksums NIST computed when signing do not match the checksums >> of the canonicalized XML that contains the fixed attributes. >> >> Whether or not there is a security implication (and I maintain that >> it seems likely that there is), this is a serious interoperability >> problem. It should not matter which work-around one employs, they >> should all work exactly the same. Do you not agree? >> >> Unfortunately, as to your point about the role of XSD vs DTD in >> canonicalization -- I'm afraid I don't understand it. The fact that >> c14n11 predates XSD. There is no DTD for the SCAP datastream format, >> is there? There is only an XSD schema. If there were a DTD, I bet >> we'd have the same problem with fixed attributes. So, either one >> applies the same canonicalization logic to the completely analogous >> constructs in XSD, or another canonicalization method should have >> been chosen (although in practice there seems to be only >> xml-c14n11)? I've emailed John Boyer, the author of C14N11, for >> clarification. >> >> Regards, >> --David Solin >> >> On 10/16/2014 11:10 PM, Booth, Harold wrote: >> >> I apologize for the delay in responding to this thread and the >> length of the response. Although I am only including the initial >> message which started this thread, I am attempting to address all >> of the issues raised. >> >> Before digging too deeply I want to be sure we are all making the >> same assumptions. When reading “Canonical XML Version 1.1” >> (http://www.w3.org/TR/xml-c14n11/) (or the 1.0 version for that >> matter) it is important to note that the term “validating >> processor” is only in reference to DTD and not to Schema. >> >> The requirements that canonicalization imposes in reference to >> validating are only for those documents which are described using >> a DTD. If you read the recommendations with the DTD assumption in >> mind then the requirements contained in the canonicalization >> recommendations should hopefully be more clear. >> >> With regard to the interoperability issue with the USGCB content >> and the assertion of a vulnerability I believe this may be a >> misunderstanding. Addressing the vulnerability issue, I found a >> good explanation for wrapping attacks here: >> http://santuario.apache.org/java150releasenotes.html(toward the >> bottom of the page): >> >> “A Signature Wrapping attack can occur when a malicious entity >> duplicates some signed Element in a document, and then modifies >> the content of the duplicated Element, but keeps the same Id. If >> the signature validation process only finds the initial Element, >> then signature validation will pass, and the user might be fooled >> into thinking that the modified Element has been signed, as it >> has the same Id as the original validated Element. >> >> The implication of this attack is that it is vital that the user >> checks that the Elements that were signed correspond to the >> Elements that he/she expects to be signed. In other words, the >> Elements that were signed should be located in a specific "known" >> place in the Document. The best way of facilitating this check is >> to make sure that the signature validation process returns the >> Elements that it validated.” >> >> Additionally, the “XML Signature Best Practices” working group >> note found at: >> http://www.w3.org/TR/2013/NOTE-xmldsig-bestpractices-20130411/has >> an example as well in section 3.1.5. >> >> Please note the responsibility for preventing ID wrapping attacks >> largely fall on the verifier in this case and not on the signer. >> If for some reason an application requires usage of an unsigned >> element (violating the best practice in section 3.2.1) then that >> would be a problem with the signature of the document and >> therefore be the responsibility of a signer. >> >> Which leads into the change Oracle/Apache made to prevent >> wrapping attacks. Instead of looking for an ID and using the >> first one found (which may or may not necessarily be the first >> one in the file) they added a couple of mechanisms to allow a >> verifier to control what elements are returned during the >> verification process when ID elements need to be resolved. At the >> bottom of the bug referenced in the initial email there are three >> workarounds offered: >> >> “1. Use a validating schema which will register the elements with >> ID references. >> >> 2. Register the ID elements with the >> DOMValidateContext.setIdAttributeNS method before validating the >> signature >> >> 3. Implement a custom URIDereferencer which can find these >> references and override the built-in URIDereferencer with the >> DOMValidateContext.setURIDereferencer method.” >> >> Will option 2 or 3 work for you? With options 2 and 3 it is >> assumed the application will use the same logic when providing >> the elements for verification as when the application uses the >> elements after verification. As long as the elements with a >> particular ID that were used in signing are returned when >> requested during verification at the appropriate time >> verification should complete successfully. >> >> There may also be a fourth option available which would be to >> call setIdAttribute on the appropriate DOM element nodes prior to >> verification (or signing) (this may depend on the implementation >> of the library, but appears to work for the Apache Santuario >> library). >> >> If I missed or overlooked something please let me know. >> >> Regards, >> >> -Harold >> >> ________________________________ >> >> From: scap-dev-bounces@nist.gov >> <mailto:scap-dev-bounces@nist.gov> [scap-dev-bounces@nist.gov >> <mailto:scap-dev-bounces@nist.gov>] on behalf of David Solin >> [david@joval.org <mailto:david@joval.org>] >> >> Sent: Wednesday, October 01, 2014 11:37 AM >> >> To: OVAL Developer List (Closed Public Discussion); >> scap-dev@nist.gov <mailto:scap-dev@nist.gov> >> >> Subject: [scap-dev] Broken XML signatures in USGCB datastreams >> >> [Note: cross-posted to OVAL-dev and SCAP-dev lists] >> >> About a year ago, Oracle made a change to the behavior of XML >> signature validation in Java: >> >> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8017171 >> >> While implementing a work-around, we discovered that the breaking >> change was actually a fix for ID-wrapping attacks. It >> essentially requires developers to perform schema validation when >> validating an XML signature in Java. >> >> This is all well and good. But when you canonicalize XML in a >> schema-validating context, it turns out that all of the USGCB >> datastream signatures are actually broken. >> >> The XML signatures specify the >> http://www.w3.org/2006/12/xml-c14n11 >> <http://www.w3.org/2006/12/xml-c14n11> canonicalization >> algorithm, which is documented here: >> >> http://www.w3.org/TR/2007/CR-xml-c14n11-20070621/ >> >> Note the following bullets in the definition of canonical form >> (from the W3C page): >> >> * Attribute values are normalized, as if by a validating >> processor >> >> * Default attributes are added to each element >> >> The Datastream ComponentRef elements have a fixed attribute, >> type="simple", which in the case of the USGCB datastreams, were >> not canonicalized at the time the documents were signed (they are >> not represented in the original documents, but the schema implies >> their presence). >> >> This is not a Java problem, this applies equally to any >> implementation of XMLDSIG. When using a schema-validating parser >> (which you should always do according to the canonicalization >> specification), signature validation for the USGCB datastreams >> will fail! >> >> The implication is that the USGCB datastreams can only be >> signature-validated by non-schema-validating parsers, making them >> all susceptible to wrapping attacks. They must all be re-signed. >> >> Are we the first to notice this? >> >> Regards, >> >> --David Solin >> >> >> >> >> _______________________________________________ >> >> scap-dev mailing list >> >> scap-dev@nist.gov <mailto:scap-dev@nist.gov> >> >> To unsubscribe, send an email message toscap-dev-unsubscribe@nist.gov <mailto:scap-dev-unsubscribe@nist.gov>. >> >> -- >> >> jOVAL.org: SCAP Simplified. >> Learn More <http://www.joval.org>| Features >> <http://www.joval.org/features/>| Download >> <http://www.joval.org/download/> >> >> >> >> _______________________________________________ >> scap-dev mailing list >> scap-dev@nist.gov <mailto:scap-dev@nist.gov> >> To unsubscribe, send an email message toscap-dev-unsubscribe@nist.gov <mailto:scap-dev-unsubscribe@nist.gov>. > > > -- > > jOVAL.org: SCAP Simplified. > Learn More <http://www.joval.org> | Features > <http://www.joval.org/features/> | Download > <http://www.joval.org/download/> > > > -- > > jOVAL.org: SCAP Simplified. > Learn More <http://www.joval.org> | Features > <http://www.joval.org/features/> | Download > <http://www.joval.org/download/> > > >
Received on Wednesday, 22 October 2014 21:38:25 UTC