oss-security - Re: CVE Request: ruby openssl hostname verification issue

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160615154451.GK360@suse.de>
Date: Wed, 15 Jun 2016 17:44:51 +0200
From: Marcus Meissner <meissner@...e.de>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE Request: ruby openssl hostname verification issue

Hi Mitre,

Sorry for answering late.

I agree with your assessments of "underdocumentation, but not
generally buggy".

I also do not see a need for a CVE of this race condition.

I hereby retract the CVE request.

Sorry for the noise.

Ciao, Marcus
On Thu, Jun 09, 2016 at 01:52:49PM -0400, cve-assign@...re.org wrote:
> > This probably warrants a CVE:
> > 
> > https://github.com/ruby/openssl/issues/8
> 
> 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.,
> 
>   https://curl.haxx.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html
>   "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
>   that."
> 
> 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
>   http://cve.mitre.org/cve/request_id.html ]
> 

-- 
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meissner@...e.de>
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.