← Prev in month ← Prev in thread

Conformance profiles for ebMS V3: need an update?

From
Jacques Durand
Date
2008-07-16T21:20:00+00:00
ID
Thread
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:]
Sent: Thursday, July 10, 2008 
2:25 AM
To: Durand, Jacques R.
Subject: xml signature 
security issue




FYI

> -----Ursprüngliche Nachricht-----
> Von:  
[mailto:] 
> Gesendet: Donnerstag, 12. Juli 2007 
22:35
> An: 
> 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)
__________________________________________________________________
← Prev in month ← Prev in thread