strongSwan X.509 Validation Error Lets Remote Users Authenticated to Protected Networks
SecurityTracker Alert ID: 1010589|
SecurityTracker URL: http://securitytracker.com/id/1010589
(Links to External Site)
Date: Jun 26 2004
Host/resource access via network|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes |
Version(s): 2.1.2 and prior versions|
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().
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.|
The vendor has released a fixed version (2.1.3), available at:|
Vendor URL: strongswan.org/ (Links to External Site)
Linux (Any), UNIX (Any)|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Date: Wed Jun 16 15:36:44 CEST 2004|
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:
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"
What do you think? Have I missed something substantial?
BTW: Sorry for posting you mailing lists. I didn't found any security