An old bug in our TLS library that caused IKE/EAP identities to not get matched against certificates in TLS-based EAP methods can possibly lead to an authorization bypass vulnerability. This bug was fixed with 5.9.6. However, there are still vulnerable versions packaged by distributions.
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 ext-auth, updown, or whitelist plugins).
Remote code execution is not possible due to this issue.
Credit to Jan Schermer for pointing out the issue with matching IKE identities in vulnerable versions and reporting it responsibly.
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.
For affected releases, we provide patches that fix the vulnerability and should apply with appropriate hunk offsets.