strongSwan Releases Patch for CVE-2023-26463 that Could Lead to RCE Attacks
Are you using strongSwan for VPN connections? If so, you need to be aware of a security vulnerability that has been discovered in the software. This vulnerability can allow an attacker to bypass authentication and potentially execute remote code on your system.
strongSwan is a complete IPsec solution providing encryption and authentication to servers and clients. strongSwan can be used to secure communications with remote networks so that connecting remotely is the same as connecting locally.
The Vulnerability
The vulnerability, identified as CVE-2023-26463, is related to certificate verification in TLS-based EAP methods. An attacker can send a self-signed or untrusted certificate to a server that authenticates clients with a TLS-based EAP method, such as EAP-TLS. The TLS implementation in libtls incorrectly treats the public key from the peer’s certificate as trusted, even if the certificate can’t be verified successfully. This can lead to an authentication bypass and subsequently to an expired pointer dereference that results in a denial of service, information exposure, or even remote code execution.
Mitigation
The just-released strongSwan 5.9.10 version includes a fix for the CVE-2023-26463 flaw. However, if you’re using an older release, you can still protect your system by applying the provided patch that fixes the vulnerability.
If you’re a server administrator, you can protect your system by ensuring that plugins that implement TLS-based EAP methods, such as EAP-TLS, EAP-TTLS, EAP-PEAP, and EAP-TNC, are not loaded. If they are loaded, they should not be configured as the remote authentication method. The EAP-dynamic plugin should also not be used as it allows clients to select their preferred EAP method. Servers that use TLS-based methods via the eap-radius plugin and only configure that as the remote authentication method are not vulnerable.
For clients, it’s important to ensure that plugins for TLS-based EAP methods are not loaded, or if they are, they should not be configured as the authentication method. If a non-TLS EAP method is configured, the client will respond with an EAP-Nak if the server requests a TLS-based method, even if a plugin that implements the method is loaded.