Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (VPN)  >   strongSwan Vendors:
strongSwan X.509 Validation Error Lets Remote Users Authenticated to Protected Networks
SecurityTracker Alert ID:  1010589
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jun 26 2004
Impact:   Host/resource access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 2.1.2 and prior versions
Description:   An authentication vulnerability was reported in strongSwan. A remote user can authenticate to a network that uses strongSwan.

Thomas Walpuski reported that a remote user can send a specially crafted certifcate authority (CA) certificate wrapped in PKCS#7 to cause the user's fake CA certificate to be entered into the CA certificate storage on the target system. This can be achieved by sending an end user certificate with identical issuer and subject distinguished names (DNs) and a fake CA certificate with the same subject DN as the end user certificate's subject DN, the report said.

The flaw is reportedly due to a logic error in verify_x509cert().

Impact:   A remote user can cause a target system to store a fake CA certificate, thereby allowing the remote user to authenticate to an ostensibly protected system or network.
Solution:   The vendor has released a fixed version (2.1.3), available at:

Vendor URL: (Links to External Site)
Cause:   Authentication error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Jun 26 2004 (Gentoo Issues Fix) strongSwan X.509 Validation Error Lets Remote Users Authenticated to Protected Networks
Gentoo has released a fix.

 Source Message Contents

Subject:  [Openswan dev] potential authentication bug in strongSwan/Openswan

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

         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
	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


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC