OpenSSL vulnerability CVE-2015-0205

Question

I can't seem to make any sense out of the following vulnerability in OpenSSL:

DH client certificates accepted without verification [Server] (CVE-2015-0205)
=============================================================================

Severity: Low

An OpenSSL server will accept a DH certificate for client authentication
without the certificate verify message. This effectively allows a client
to authenticate without the use of a private key. This only affects servers
which trust a client certificate authority which issues certificates
containing DH keys: these are extremely rare and hardly ever encountered.

This issue affects OpenSSL versions: 1.0.1 and 1.0.0.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
Henson of the OpenSSL core team.

The reason why the above does not make sense is that when a DH certificate is used by the client, the client is not expected to send a Certificate Verify message, a per RFC 5246, section 7.4.8:

  This message is used to provide explicit verification of a client
  certificate.  This message is only sent following a client
  certificate that has signing capability (i.e., all certificates
  except those containing fixed Diffie-Hellman parameters).

And here is what RFC 5246, section F.1.1.3 says:

  When Diffie-Hellman key exchange is used, the server can either
  supply a certificate containing fixed Diffie-Hellman parameters or
  use the server key exchange message to send a set of temporary
  Diffie-Hellman parameters signed with a DSA or RSA certificate.
  Temporary parameters are hashed with the hello.random values before
  signing to ensure that attackers do not replay old parameters.  In
  either case, the client can verify the certificate or signature to
  ensure that the parameters belong to the server.

  If the client has a certificate containing fixed Diffie-Hellman
  parameters, its certificate contains the information required to
  complete the key exchange.  Note that in this case the client and
  server will generate the same Diffie-Hellman result (i.e.,
  pre_master_secret) every time they communicate.  To prevent the
  pre_master_secret from staying in memory any longer than necessary,
  it should be converted into the master_secret as soon as possible.
  Client Diffie-Hellman parameters must be compatible with those
  supplied by the server for the key exchange to work.

Moreover, I fail to see how one could impersonate the client (i.e. compute the pre_master_secret) without knowing the client's secret key.

I can see how a bug in OpenSSL could allow an attacker to bypass authentication, for example if OpenSSL would accept DH parameters in the Client Key Exchange message, i.e. if OpenSSL did not properly enforce this part of RFC 5246, section 7.4.7:

  When the client is using an ephemeral Diffie-Hellman exponent,
  then this message contains the client's Diffie-Hellman public
  value.  If the client is sending a certificate containing a static
  DH exponent (i.e., it is doing fixed_dh client authentication),
  then this message MUST be sent but MUST be empty.

But the fix does not support this interpretation. Indeed, it appears to require a Certificate Verify message!

Can anyone make sense of this?

Erwan Legrand · Accepted Answer · 2015-01-29T17:11:49.430

In the end, the following hypothesis from my question above proved to be true:

I can see how a bug in OpenSSL could allow an attacker to bypass authentication, for example if OpenSSL would accept DH parameters in the Client Key Exchange message, i.e. if OpenSSL did not properly enforce this part of RFC 5246, section 7.4.7

This code comes from the ssl3_get_client_key_exchange() function in OpenSSL:

https://github.com/openssl/openssl/blob/474e469bbd056aebcf7e7d3207ef820f2faed4ce/ssl/s3_srvr.c#L2325

if (n == 0L) {
  /* Get pubkey from cert */
  EVP_PKEY *clkey = X509_get_pubkey(s->session->peer);
  if (clkey) {
    if (EVP_PKEY_cmp_parameters(clkey, skey) == 1)
      dh_clnt = EVP_PKEY_get1_DH(clkey);
  }
  if (dh_clnt == NULL) {
    al = SSL_AD_HANDSHAKE_FAILURE;
    SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE,
    SSL_R_MISSING_TMP_DH_KEY);
    goto f_err;
  }
  EVP_PKEY_free(clkey);
  pub = dh_clnt->pub_key;
} else
  pub = BN_bin2bn(p, i, NULL);
if (pub == NULL) {
  SSLerr(SSL_F_SSL3_GET_CLIENT_KEY_EXCHANGE, SSL_R_BN_LIB);
  goto err;
}

The above code does not prevent the client (or a MITM) to provide at the same time a DH certificate and DH parameters in the Client Key Exchange message. When the message is not empty, the public key is read from the message:

} else
  pub = BN_bin2bn(p, i, NULL);

Thus an attacker could provide a certificate and perform the DH key exchange using another public key than the one in the certificate!

For some reason, the OpenSSL developers choose not to require an empty Client Key Exchange message when the client provides a DH cert. (Even though this is required by the RFC.)

The reason why the fix from the OpenSSL team does not break client authentication with DH certs is the ssl3_get_cert_verify() function is not called if ssl3_get_client_key_exchange() read the key from the certificate. The logic is somewhat convoluted but... well, it works!

score 1 · Answer 2 · answered Jan 27 '15 at 05:45

1

I completely agree with you. There is no scope of certificate verify message in the case of ephermeral DH as signing is not involved in any part of authentication.

answered Jan 27 '15 at 05:45

user45475

1,030
2
9
14

Obviously you meant **non-ephemeral** DH? – Erwan Legrand Jan 27 '15 at 10:27
I think, this link will help you more about the clarification of your answer. [http://security.stackexchange.com/questions/37797/how-does-non-ephemeral-diffie-hellman-key-exchange-become-compromised-in-ssl-whe] If require , we will discuss more. Cheers :) – user45475 Jan 28 '15 at 01:44

OpenSSL vulnerability CVE-2015-0205

2 Answers2