OASIS ebXML Messaging Services TC

 View Only

  • 1.  Conformance profiles for ebMS V3: need an update?

    Posted 07-16-2008 21:20 
    






    Feedback obtained at ETSI, on the Conformance Profiles 
adjunct document:
    

     
    

    - the eb:Receipt is not profiled enough, in these conf 
profiles. The content is still left TBD (a SHOULD in the core 
spec)
    

    - security threat below:  need be accommodated in 
the profile?
    

    - Editorial: I noticed that two subsections are missing 
in the first Gateway RM V3 profile: 2.2.2, 2.2.3 (accidental deletion I 
guess)
    

     
    

    2 The Gateway Conformance 
Profile........................................................................................................... 
7
    

    2.1 
Purpose............................................................................................................................................ 
7
    

    2.2 Conformance Profile: 
Gateway RM 
V3.............................................................................................. 
7
    

    2.2.1 Feature 
Set................................................................................................................................ 
7
    

    

    2.2.2 WS-I Conformance 
Requirements............................................................................................. 

    

    2.2.3 Processing Mode 
Parameters.................................................................................................. 

    

    2.3 Conformance Profile: 
Gateway RX 
V3............................................................................................... 
9
    

    2.3.1 Feature 
Set................................................................................................................................ 
9
    

    2.3.2 WS-I Conformance 
Requirements............................................................................................. 
9
    

    2.3.3 Processing Mode 
Parameters.................................................................................................. 
10
    

    2.4 
Conformance Profile: 
....
    


    Jacques
    

     
    

     
    

    

    
From: Häusler, Michael 
[mailto:haeusler@ponton-consulting.de]
    Sent: Thursday, July 10, 2008 
2:25 AM
    To: Durand, Jacques R.
    Subject: xml signature 
security issue

    

    

    

    FYI
    

    

    > -----Ursprüngliche Nachricht-----
    

    > Von: brad@isecpartners.com 
[mailto:brad@isecpartners.com] 
    

    > Gesendet: Donnerstag, 12. Juli 2007 
22:35
    

    > An: bugtraq@securityfocus.com
    

    > Betreff: Whitepaper: Command 
Injection in XML Digital 
    

    > Signatures and 
Encryption
    

    > 
    

    > 
    

    > iSEC Partners and Brad Hill are 
pleased to announce the 
    

    > availability of a new whitepaper 
describing design flaws and 
    

    > new attacks against the XML Digital 
Signature and XML 
    

    > Encryption standards.  It 
accompanies recent advisories and 
    

    > provides detailed guidance for 
auditors and implementers of 
    

    > these 
products.
    

    > 
    

    > Full Paper Available 
at:
    

    > 
------------------------
    

    > 
    

    http://www.isecpartners.com/files/XMLDSIG_Command_Injection.pdf
    

    

    Abstract: 
    

    ---------
    

    

    The XML Digital Signature (XMLDSIG) and 
XML Encryption (XMLENC) standards are complex protocols for securing XML and 
other content. Among its complexities, the XMLDSIG standard specifies various 
“Transform” algorithms to identify, manipulate and canonicalize signed content 
and key material. Unfortunately, the defined transforms have not been rigorously 
constrained to prevent their use as attack vectors, and denial of service or 
even arbitrary code execution are probable in implementations that have not 
specifically guarded against such risks. 
    

    

    Attacks against the processing 
application can be embedded in the KeyInfo portion of a signature, making them 
inherently unauthenticated, or in the SignedInfo block. Although tampering with 
the SignedInfo should be detectable, a defective implied order of operations in 
the specification may still allow unauthenticated attacks here. 

    

    

    The ability to execute arbitrary code and 
perform file system operations with a malicious, invalid signature has been 
confirmed by the researcher in at least two independent XMLDSIG implementations, 
and other implementations may be similarly vulnerable. This paper describes the 
vulnerabilities in detail and offers advice for remediation. The most damaging 
attack is also likely to apply in other contexts where XSLT is accepted as 
input, and should be considered by all implementers of complex XML processing 
systems.
    

    

    About iSEC 
Partners:
    

    --------------------
    

    iSEC Partners is a full-service security 
consulting firm that provides
    

    penetration testing, secure systems 
development, security education
    

    and software design 
verification.
    

    

    115 Sansome Street, Suite 
1005
    

    San Francisco, CA 
94104
    

    Phone: (415) 
217-0052
    

    

    

    --
    Mit freundlichen Grüßen / Best 
Regards,
    Michael 
Häusler
    __________________________________________________________________
    Ponton 
Consulting GmbH                
 voice:  + 49.40.69213-340
    http://www.ponton-consulting.de/       fax:    + 
49.40.69213-355
    Dorotheenstraße 60
    D-22301 
Hamburg
    __________________________________________________________________

    HRB 
81480, AG Hamburg, Managing Director: Dr. Michael Merz
    Ponton Consulting is a 
Member of C1 Group 
(www.c1-group.com)
    __________________________________________________________________


  • 2.  RE: [ebxml-msg] Conformance profiles for ebMS V3: need an update?

    Posted 09-09-2008 22:55 
    






    Following-up on this old feedback on the Conformance 
Profiles CD, uploaded an update 
    


     
    

    1. Missing subsections: have been re-inserted (see uploaded 
V0.3).
    

    2. Under specified eb:Receipt requirement: propose to 
insert the following (see in the 2.2.1 Feature Set table)
    

    

    Regardless of which MEP is used, 
the sending of an eb:Receipt message must be supported:
    

      
  
    • 
  
      For the One-way / Push, both 
  “response” and “callback” reply patterns must be supported.
      
  
    • 
  
      For the One-way / Pull, the 
  “callback” pattern is the only viable option, and the User message sender MUST 
  be ready to accept an eb:Receipt either piggybacked on a PullRequest, or sent 
  separately. The User message receiver MUST be able to send an eb:Receipt 
  separately from the PullRequest.
      
  
    • 
  
      For the Two-way / Sync, both 
  “response” and “callback” reply patterns must be supported for the first leg. 
  The “callback” pattern is the only viable option for the second leg. The reply 
  sender MUST be ready to accept an eb:Receipt either piggybacked on another 
  User message, or sent separately. The reply receiver MUST be able to send an 
  eb:Receipt separately.
    

    Use of the 
ebbpsig:NonRepudiationInformation element (as defined in [ebBP-SIG] 
MUST be supported as content for the 
eb:Receipt message.
    

     
    

    3. 
Security threat for XML DSig: anything to be done here? http://www.isecpartners.com/files/XMLDSIG_Command_Injection.pdf
    

     
    

    Jacques
    

     
    

    

    

    

    From: Durand, Jacques R. 
[mailto:JDurand@us.fujitsu.com]
    Sent: Wednesday, July 16, 2008 2:20 
PM
    To: ebxml-msg@lists.oasis-open.org
    Subject: [ebxml-msg] 
Conformance profiles for ebMS V3: need an update?

    

    

    Feedback obtained at ETSI, on the Conformance Profiles 
adjunct document:
    

     
    

    - the eb:Receipt is not profiled enough, in these conf 
profiles. The content is still left TBD (a SHOULD in the core 
spec)
    

    - security threat below:  need be accommodated in 
the profile?
    

    - Editorial: I noticed that two subsections are missing 
in the first Gateway RM V3 profile: 2.2.2, 2.2.3 (accidental deletion I 
guess)
    

     
    

    2 The Gateway Conformance 
Profile........................................................................................................... 
7
    

    2.1 
Purpose............................................................................................................................................ 
7
    

    2.2 Conformance Profile: 
Gateway RM 
V3.............................................................................................. 
7
    

    2.2.1 Feature 
Set................................................................................................................................ 
7
    

    

    2.2.2 WS-I Conformance 
Requirements............................................................................................. 

    

    2.2.3 Processing Mode 
Parameters.................................................................................................. 

    

    2.3 Conformance Profile: 
Gateway RX 
V3............................................................................................... 
9
    

    2.3.1 Feature 
Set................................................................................................................................ 
9
    

    2.3.2 WS-I Conformance 
Requirements............................................................................................. 
9
    

    2.3.3 Processing Mode 
Parameters.................................................................................................. 
10
    

    2.4 
Conformance Profile: 
....
    


    Jacques
    

     
    

     
    

    

    
From: Häusler, Michael 
[mailto:haeusler@ponton-consulting.de]
    Sent: Thursday, July 10, 2008 
2:25 AM
    To: Durand, Jacques R.
    Subject: xml signature 
security issue

    

    

    

    FYI
    

    

    > -----Ursprüngliche Nachricht-----
    

    > Von: brad@isecpartners.com 
[mailto:brad@isecpartners.com] 
    

    > Gesendet: Donnerstag, 12. Juli 2007 
22:35
    

    > An: bugtraq@securityfocus.com
    

    > Betreff: Whitepaper: Command 
Injection in XML Digital 
    

    > Signatures and 
Encryption
    

    > 
    

    > 
    

    > iSEC Partners and Brad Hill are 
pleased to announce the 
    

    > availability of a new whitepaper 
describing design flaws and 
    

    > new attacks against the XML Digital 
Signature and XML 
    

    > Encryption standards.  It 
accompanies recent advisories and 
    

    > provides detailed guidance for 
auditors and implementers of 
    

    > these 
products.
    

    > 
    

    > Full Paper Available 
at:
    

    > 
------------------------
    

    > 
    

    http://www.isecpartners.com/files/XMLDSIG_Command_Injection.pdf
    

    

    Abstract: 
    

    ---------
    

    

    The XML Digital Signature (XMLDSIG) and 
XML Encryption (XMLENC) standards are complex protocols for securing XML and 
other content. Among its complexities, the XMLDSIG standard specifies various 
“Transform” algorithms to identify, manipulate and canonicalize signed content 
and key material. Unfortunately, the defined transforms have not been rigorously 
constrained to prevent their use as attack vectors, and denial of service or 
even arbitrary code execution are probable in implementations that have not 
specifically guarded against such risks. 
    

    

    Attacks against the processing 
application can be embedded in the KeyInfo portion of a signature, making them 
inherently unauthenticated, or in the SignedInfo block. Although tampering with 
the SignedInfo should be detectable, a defective implied order of operations in 
the specification may still allow unauthenticated attacks here. 

    

    

    The ability to execute arbitrary code and 
perform file system operations with a malicious, invalid signature has been 
confirmed by the researcher in at least two independent XMLDSIG implementations, 
and other implementations may be similarly vulnerable. This paper describes the 
vulnerabilities in detail and offers advice for remediation. The most damaging 
attack is also likely to apply in other contexts where XSLT is accepted as 
input, and should be considered by all implementers of complex XML processing 
systems.
    

    

    About iSEC 
Partners:
    

    --------------------
    

    iSEC Partners is a full-service security 
consulting firm that provides
    

    penetration testing, secure systems 
development, security education
    

    and software design 
verification.
    

    

    115 Sansome Street, Suite 
1005
    

    San Francisco, CA 
94104
    

    Phone: (415) 
217-0052
    

    

    

    --
    Mit freundlichen Grüßen / Best 
Regards,
    Michael 
Häusler
    __________________________________________________________________
    Ponton 
Consulting GmbH                
 voice:  + 49.40.69213-340
    http://www.ponton-consulting.de/       fax:    + 
49.40.69213-355
    Dorotheenstraße 60
    D-22301 
Hamburg
    __________________________________________________________________

    HRB 
81480, AG Hamburg, Managing Director: Dr. Michael Merz
    Ponton Consulting is a 
Member of C1 Group 
(www.c1-group.com)
    __________________________________________________________________


Related Content