Summary
Certificate verification was loading CA certificates from OpenSSL default locations. This could cause certificates from unexpected CAs to be considered valid when validating certificate chains.
Affected Radiator versions
All Radiator versions that support TLS-based EAP methods or TLS-based Stream modules, such as RadSec and Diameter, are affected.
Affected Radiator configurations
EAP configurations that use EAP-TLS are affected. If EAP-TLS configuration uses only CA chain validity checks, certificates signed by undesired CAs may be accepted by Radiator. Additional checks done when EAPTLS_NoCheckId configuration parameter is not enabled may mitigate the issue. This parameter is not enabled by default and it is typically enabled only when no other check than CA chain check is required. This issue may also be mitigated when EAPTLS_CertificateVerifyHook and EAPTLS_PolicyOID parameters are used in the configuration.
Stream-based modules that use TLS, such as RadSec and Diameter, are affected. If TLS peers use only CA chain validity checks, certificates signed by undesired CAs may be accepted. This issue may be mitigated with various TLS configuration parameters, such as TLS_PolicyOID, TLS_ExpectedPeerName and other parameters that enable additional certificate checks.
EAP-TTLS and PEAP configurations that use uncommon configuration parameter EAPTLS_RequireClientCert are affected.
Recommended action
OSC recommends upgrading to Radiator 4.20.
- Download and upgrade to Radiator 4.20.
- Restart Radiator after the upgrade.
Mitigation
If you cannot upgrade at this time, consider the following mitigation options.
1. Change OpenSSL default locations
Set the both environment variables SSL_CERT_DIR and SSL_CERT_FILE to a non-existent value before starting Radiator.
For example, when the both variables are set to ‘not-a-file-or-dir’, OpenSSL library tries to use this value as the file and directory location. Because the location does not exist, no certificates are loaded. This does not affect Radiator EAPTLS_CAFile, TLS_CAFile and other certificate related configuration parameters.
2. Configure additional certificate checks
If EAP-TLS configuration has NoCheckId enabled and thus certificates are not searched from a database Radiator uses, consider the first mitigation option or configure additional checks. Additional checks may be configured with EAPTLS_CertificateVerifyHook and EAPTLS_PolicyOID to match possible certificate extensions and other values.
Stream-based configurations, such as RadSec and Diameter, may be able to use TLS_ExpectedPeerName, TLS_PolicyOID and other configuration parameters to require additional certificate validity checks.
Related configuration changes
If your configuration requires CA certificates from the default locations, enable this with configuration flag parameters EAPTLS_UseCADefaultLocations and TLS_UseCADefaultLocations for TLS-based EAP methods and Stream modules, respectively. These flags were added in Radiator 4.20.
Questions and answers
How can an attacker use this vulnerability?
The attacker may pass certificate-based authentication with a certificate signed by an undesired CA.
What is required to exploit this vulnerability?
When Radiator is configured with certificate checks that are based only on CA chain validity, an attacker needs a certificate that can be validated against a CA certificate in OpenSSL default locations.
How was this vulnerability discovered?
This vulnerability was discovered by OSC’s development team.
OSC is not aware of use of this vulnerability.