Bug 1223543 (CVE-2022-4967) - VUL-0: CVE-2022-4967: strongswan: Potential Authorization Bypass With TLS-based EAP Methods
Summary: VUL-0: CVE-2022-4967: strongswan: Potential Authorization Bypass With TLS-bas...
Status: RESOLVED FIXED
Alias: CVE-2022-4967
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Duraisankar P
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-29 15:00 UTC by Alexander Bergmann
Modified: 2024-05-20 07:39 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bergmann 2024-04-29 15:00:22 UTC
Dear strongSwan partner,

This is an advisory to reclassify an old bug in our TLS library as a
potential authorization bypass vulnerability in order to get the fix
applied to affected distribution packages. The bug is contained in
versions 5.9.2 through 5.9.5 and was fixed with 5.9.6, which was
released in August 2022.


# Potential Authorization Bypass With TLS-based EAP Methods

When certificates are used to authenticate clients in TLS-based EAP
methods, the IKE or EAP identity supplied by a client is not enforced to
be contained in the client's certificate. So clients can authenticate
with any trusted certificate and claim an arbitrary IKE/EAP identity as
their own. This is problematic if the identity is used to make policy
decisions. Affected are strongSwan versions 5.9.2 through 5.9.5.

CVE-2022-4967 has been assigned for this vulnerability.


## Wrong Identity Used in Lookup for Client Certificate

The changes that added TLS 1.3 to our TLS library (libtls) with 5.9.2
refactored the lookup for trusted client certificates on the server.
Instead of continuing to use the IKE or EAP identity supplied by the
client to find a matching certificate, the lookup was done with the
client certificate's subject DN, which will always succeed as long as
the certificate is trusted. So the client could claim an arbitrary
IKE/EAP identity that would not have to be contained in its certificate.

This is a problem if that identity is used to make policy decisions
either via strongSwan's configuration (e.g. switching between multiple
connections that allow access to different networks) or via
plugins/scripts that match the identity (e.g. via the whitelist,
ext-auth or updown plugins).

Remote code execution is not possible due to this issue.


# Mitigation

Again, setups that use strongSwan versions older than 5.9.2 or newer
than 5.9.5 are not affected.

Setups that don't match client identities when using TLS-based EAP
methods are also not vulnerable as clients still have to use a trusted
certificate.

The attached patch fixes the vulnerability in the affected strongSwan
versions and should apply with appropriate hunk offsets.

Please prepare updated releases and patch your installations, but do not
yet publicly disclose any information about the vulnerability. We want
to give you as a partner enough time to prepare new releases and will
publicly disclose the vulnerability on Mon May 13, 14:00 CEST.

Credit to Jan Schermer for pointing out the issue with matching IKE
identities in vulnerable versions and reporting it responsibly.

Our apologies for the inconvenience.

Kind Regards
Tobias Brunner
strongSwan Developer
Comment 1 Alexander Bergmann 2024-04-29 15:01:01 UTC
Created attachment 874565 [details]
strongswan-5.9.2-5.9.5_tls_enforce_client_identity.patch