Andreas Steffen writes: 
8<----------------------------------------------------------------- 
[-- Attachment #1 [details] --] 
[-- Type: text/plain, Encoding: 8bit, Size: 2.8K --] 
 
Hello Thomas, 
 
you are right. The support of PKCS#7 wrapped certificates as required 
e.g. by Windows XP with multi-tier trust chains introduced the 
vulnerability that you describe in your posting. The proposed fix is simple. 
We will not accept any end certificates with identical subject and 
issuer distinguished names before the trust chain verification loop 
is entered. 
 
I have appended a patch which fixes the vulnerability for openswan-2.x, 
strongswan-2.x and all X.509 patches for freeswan-2.x. A similar patch 
will be made available for freeswan-1.99 based releases. The most 
recent versions of openswan, strongswan and the X.509 patches will be 
updated. 
 
Thanks for making me aware of this serious vulnerability. 
 
Andreas 
 
Thomas Walpuski wrote: 
>It looks like there is an authentication bug in strongSwan/Openswan.                            
>(I've not verified the issue on a running system, yet.)                                         
>                                                                                                
>If an attacker sends a his (fake) CA certificate with issuer A and                              
>subject B and user certificate with issuer B and subject B signed by his                        
>CA wrapped in PKCS#7 as certificate payload the following happens:                              
>                                                                                                
>  0 ...                                                                                         
>  1 decode_cert() lets parse_pkcs7_cert() parse the certificate payload                         
>    and passes the result to store_x509certs().                                                 
>  2.1 store_x509certs() walks through the CA certificate(s), ensures                            
>      that it is no root CA (subject /= issuer) and enters it to the CA                         
>      certificate storage. => The attacker's CA certificate makes it way                        
>      into the CA certificate storage.                                                          
>  2.2 store_x509certs() walks through all certificates and adds their                           
>      public key and identity to the key storage _if_ they can be                               
>      verified:                                                                                 
>                                                                                                
>        verify_x509cert() checks whether the user certificate is in its                         
>       validity period, gets the issuer's certificate and checks the                            
>       user certificate's signature. => The attacker gets his user                              
>       certificate verified, because he already got his CA certificate                          
>       in.                                                                                      
>       If the user certificates issuer and subject are the same,                                
>       verify_x509cert() returns TRUE indicating successful certificate                         
>       verification, otherwise the issuer certificate is checked. =>                            
>       In the attacker's user certificate subject = issuer, ...                                 
>                                                                                                
>With a carefully crafted certificate payload anyone can "authenticate"                          
>against strongSwan/Openswan.                                                                    
>                                                                                                
>What do you think? Have I missed something substantial?                                         
>                                                                                                
>BTW: Sorry for posting you mailing lists. I didn't found any security                           
>contact information.                                                                            
>                                                                                                
>Thomas Walpuski                                                                                 
 
======================================================================= 
Andreas Steffen                   e-mail: andreas.steffen@strongsec.com 
strongSec GmbH                    home:   http://www.strongsec.com 
Alter Zürichweg 20                phone:  +41 1 730 80 64 
CH-8952 Schlieren (Switzerland)   fax:    +41 1 730 80 65 
==========================================[strong internet security]=== 
 
8<----------------------------------------------------------------- 
 
At least SL8.1 -- 9.1 and SLES8+9 are affected.