Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu,  9 Jun 2016 13:52:49 -0400 (EDT)
Subject: Re: CVE Request: ruby openssl hostname verification issue

Hash: SHA256

> This probably warrants a CVE:

We are not sure exactly what issue you believe should have a CVE ID,
There seem to be three issues that are somewhat related. Our short
answer is "probably there shouldn't be a CVE ID - the main concern was
that the documentation needed to be improved, and the vendor instead
decided to change the API semantics and break one (rare) use case."

Here's some discussion of the three issues.

> VERIFY_PEER only checks the cert chain is rooted in the local
> truststore. It does not check if the subject is valid in and of
> itself.

One might argue that this behavior should have a CVE ID because it is
not properly documented. Some users might have guessed that
VERIFY_PEER did validate the subject, because it is very rare for
anyone to want to establish only that a certificate is rooted in the
local truststore, with any arbitrary subject.

Other products, such as libcurl, have a similarly named option with
the same behavior, but with explicit documentation, e.g.,
  "Authenticating the certificate is not enough to be sure about the
  server. You typically also want to ensure that the server is the
  server you mean to be talking to. Use CURLOPT_SSL_VERIFYHOST for

However, there apparently isn't an analogous OpenSSL::SSL::VERIFY_HOST
for Ruby.

Still, our initial thought is that underdocumenting
OpenSSL::SSL::VERIFY_PEER, by itself, should not have a CVE ID. Users
may be able to realize, possibly from their knowledge of libcurl, that
an option called VERIFY_PEER or VERIFYPEER is typically insufficient.

> My understanding is the ssl_socket.post_connection_check(hostname) method
> must be called to ensure the subject is correctly verified. However,
> communication is allowed to remote services without verifying the subject.

Here, maybe the problem is a race condition. In other words, there is
inherently a time window in which communication can occur with an
unexpected host. Possibly, in most common scenarios in which the
application author did understand the post_connection_check
documentation, nothing security-relevant happens in this time window,
e.g., a client would not be sending requests to a server before the
post_connection_check step. However, there may be uncommon scenarios
where something security-relevant can happen in this time window.

Do you believe that these uncommon scenarios actually occur, and
therefore this race condition should have a CVE ID?

> I would suggest throwing an exception if VERIFY_PEER is configured and
> I/O is attempted without first calling post_connection_check

Here, you seem to be suggesting that VERIFY_PEER is never sufficient
in any scenario. This seems to be equivalent to suggesting that the
libcurl choice of using CURLOPT_SSL_VERIFYPEER without
CURLOPT_SSL_VERIFYHOST is always wrong, and should not even be
possible in the libcurl API.

Do you believe that there should be a CVE ID, in general, for "the
product needlessly offers a way to skip subject validation"?

(We don't know all of the use cases for skipping subject validation.
We think that it is typically useful only within isolated networks.
For example, consider a scenario where the local truststore recognizes
exactly one CA, this CA has only ever issued one certificate, and the
certificate happens to have an arbitrary subject, but is intentionally
used on multiple intranet HTTPS servers that are trusted by the same
intranet clients. Here, subject validation doesn't really help anyone,
and mandating subject validation would break this use case.)

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ