Date: Thu, 9 Jun 2016 13:52:49 -0400 (EDT) From: cve-assign@...re.org To: meissner@...e.de Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request: ruby openssl hostname verification issue -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > 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 ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXWawKAAoJEHb/MwWLVhi2tgkP/2xjIkd96YWn0dYlo0XWD00s 9rdCsybI7FffGljxN0eioA33cAGbZ7Xw6OHjQMfjuV6V9eprWwjFQvRKmO/5nJcI Wqw24KonYbeoNwYZVMcESfKMefPitEUFf2FYs1blo4PoEJx+3bOUvpnA2576f11k f5mBX3GIj5SoRzxr5f3gQfVW/CZfvJgeVEmb7g/I868kXOeNPR78/OIGogj96s9v 4bOFg7nAd20uHTKScKl82Gh5VcuL4ZWaKJhVGmdC6AH/7YTLIWbFNwKWv/LhZTzl YxBl/FfZG6M1glRpqDUnIEGj0EEtA0EyTUxrtNrL0nVxxh6ZyowEAH8wlNsFuwuU KsKC7JJsrPtG+SxMXwdc10jDvUufS1XPPvm1KVOEy/MRRLWYcxlPKOGM3SD/Pchw qijozFYx59ORKg47NUVKOzvahan1GLoDXKaxXQZzN7ll6PwiKsFpEGBPbNQEsuBq gUMuws4UC1g5yD2p0RreC2X4S0EXA0MbdGo0ovIYH/C1uhJdooIQt6UvajVa9X3X 0NFnvpJuj3q+dxWD8H0BwVvg9CQTeFslD04ZMJND1TeXJWYBMElIVgDc8Bc0IYzw SRjEyqX5GK9qXiR/VOW+XhHzcRkY8Rd6n+M8timCOjqIGWu9bOhVLtKovbnudM4L 9tJEbPydeJGuvSmiEkTS =KqPE -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ