![]() ![]() Neither must the eap-dynamic plugin be used as it allows clients to select their preferred EAP method. If they are loaded, they must not be configured as remote authentication method. Servers that don't load plugins that implement TLS-based EAP methods (EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-TNC) are not vulnerable. Remote code execution might therefore be possible due to this issue. points to memory allocated to the process) and what exactly was allocated there after the public key was freed, this may cause a segmentation fault or even execute code, which could again cause a segmentation fault, but might potentially be under the attacker's control. This->public_key->destroy(this->public_key) ĭepending on whether the pointer is valid (i.e. Both the x509 and the openssl plugin use the DESTROY_IF() macro for this, which expands to something like this: The certificate object from which the reference was obtained now points to an expired pointer.Īfter the EAP authentication is complete, the peer certificate is destroyed and that pointer is dereferenced when the key's `destroy()` method is called. So once the signature is verified and the supposed reference returned from tls_find_public_key() is released, the public key object is actually destroyed. If the certificate is untrusted, `public` points to a key object whose reference was already released after determining the key type. So the authentication is bypassed and the TLS handshake continues successfully even for untrusted peer certificates. With the referenced commit this changed and `public` is always defined, even if the certificate is untrusted and the search doesn't yield a result. While (enumerator->enumerate(enumerator, ¤t, &auth))Īs can be seen, it was set if, and only if, a matching trusted public key/certificate was found, otherwise, NULL was returned. The problem is that this variable was already used in that function to store the result of the search (simplified code): So the local variable `public` is used to determine the key type, which is then passed to the search. ![]() > while (enumerator->enumerate(enumerator, ¤t, &auth)) > enumerator = lib->credmgr->create_public_enumerator(lib->credmgr, The main part of the diff of that commit looks innocent enough: an ECDSA and an RSA key for the same identity loaded by the daemon, we could avoid building an eventually unused trust chain by limiting the search to the correct key type. It uses the type of the peer's certificate's public key as input to the search. With 63fd718915b5 ("libtls: call create_public_enumerator() with key_type"), a small optimization was added to the function. Afterwards, the reference is destroyed/released. If the peer's certificate is found to be trusted, a reference to the public key is taken and returned from the function in order to verify the TLS signature (CertificateVerify for TLS 1.3, ServerKeyExchange for older versions). When libtls is verifying a peer's certificate during a TLS exchange, it calls tls_find_public_key(), which uses libstrongswan's credential manager and the peer's identity to search for a trusted public key and associated certificate that matches the one sent by the peer. Affected are strongSwan versions 5.9.8 and 5.9.9.ĬVE-2023-26463 has been assigned for this vulnerability. Clients may be similarly vulnerable to attackers that send them a request for such an EAP method followed by an untrusted server certificate. This commonly leads to a segmentation fault and a denial of service, but information exposure or code execution might be possible.Īn attacker is able to trigger this issue by sending a self-signed (or otherwise untrusted) certificate to a server that authenticates clients with a TLS-based EAP method like EAP-TLS. However, the public key also doesn't have the correct reference count, which then causes a dereference of an expired pointer (CWE-825). 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 (CWE-295). # Incorrectly Accepted Untrusted Public Key With Incorrect Refcount A user publicly reported a bug related to certificate verification in TLS-based EAP methods that leads to an authentication bypass followed by an expired pointer dereference that results in a denial of service but possibly even code execution. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |