strongSwan X.509 Validation Error Lets Remote Users Authenticated to Protected Networks
|
|
SecurityTracker Alert ID: 1010589 |
|
SecurityTracker URL: http://securitytracker.com/id/1010589
|
|
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:
http://www.strongswan.org/download.htm
|
Vendor URL: strongswan.org/ (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.
|
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:
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
|
|
