Two authentication errors within a verify_x509cert() function allows for malicious people to bypass security restrictions. Affected products include: superfreeswan 1.x, openswan 1.x to 2.x, strongSwan below 2.1.3, and any version of FreeS/WAN 1.x or 2.x with the X.509 patch.
253023ac78a99200fa4a578eb2c552042b67862d2e97d6c8f5ec337c052c25e6
Certificate chain authentication in Openswan pluto
Published:
2004-06-28
Revision of advisory:
1.0 Initial Release
1.1 Add note about infinite loop CA checking.
Location
http://www.openswan.org/support/vuln/can-2004-0590
CVE:
CAN-2004-0590
This problem was discovered by Thomas Walpuski of IKS GmbH Jena.
No exploit is known to be available.
Affected system(s)
KNOWN VULNERABLE: Linux systems running 2.0, 2.2, 2.4 or 2.6 kernels,
that are using IPsec with pluto as the IKE daemon.
* superfreeswan 1.x (all revisions with X.509 patch)
* openswan 1.x < 1.0.6
* openswan 2.x < 2.1.4
* strongSwan < 2.1.3
* Any version of FreeS/WAN 1.x with X.509 patch < 0.9.41
* Any version of FreeS/WAN 2.x with X.509 patch < 1.6.1
To be vulnerable one must be using X.509/pkix key material that is
authenticated with a CA.
Self-signed certificates that are loaded from disk are not affected, nor
are PSK, RSA (from disk or DNS) or Opportunistic Encryption.
Summary
Given a policy exists that is based upon X.509 DN identities that
permits identity "B" to establish some kind of tunnel with a gateway or
end system, and B's credentials may be attested to by a trusted
Certificate Authority "A".
This vulnerability permits a malicious end-system to make up their own
Certificate Authority A' such that it has issuer=B, and subject=A',
followed by a self-signed end-certificate with issuer B and subject B.
When presented, this certificate chain will validate permitting the
attacker to impersonate B.
The attacker must know a valid DN B to use, and must match the policy
which B is authorized to use. As openswan does not use aggressive mode
by default, (and does not include it in version 2), it is not possible
to learn identity B by passive eavesdropping. B may be guessed,
determined by social engineering, or may be retrieved by an active
man-in-the-middle attack.
An additional hole exists in the CA checking code which could create an
endless loop in verify_x509cert(), given the following chain:
User cert subject: A issuer: B
CA cert subject: B issuer: C
CA cert subject: C issuer: B
Vendor status and information
Openswan
http://www.openswan.org/
StrongSwan
http://www.strongswan.org/
FreeS/WAN
http://www.freeswan.org/ - no longer active
All vendors have been notified and have provided patched versions.
Solution
* a) apply patch or upgrade to >=1.0.6 or >=2.1.4 versions of
Openswan. patch file
<http://anoncvs.openswan.org/cgi-bin/viewcvs.cgi/openswan-1/pluto/x509.c.diff?r1=1.23&r2=1.25&diff_format=u>
* b) only accept certificates for the remote system which are signed
by the same CA as the local system. This can be done by setting
"rightca=%same".
Detailed analysis
The mechanism which is used to authenticate the certificate chain
presented by an end-system errorneously sees the issuer=B/subject=B as a
trusted root CA when it has not yet been verified.
Openswan test case fail-x509-09 provides a more detailed analysis.
Contact Information
Xelerance Corporation
Email: vuln@xelerance.com
Web: http://www.xelerance.com/
Phone: +1 905 257 3392
About CAN
The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CAN-2004-0590 to this issue. This is a candidate for inclusion in
the CVE list (http://cve.mitre.org), which standardizes names for
security problems.