Date: Wed, 29 Apr 2015 17:19:45 -0400 (EDT) From: cve-assign@...re.org To: squid3@...enet.co.nz Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE policy clarification request -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My observation of Mitre allocations has been that when a bug B is only > acting because of another A exploited first the CVE gets assigned to > the A. In this case the client willingness to accept fake certificate > makes it vulnerable to mistakes in the proxy. > > Is my observation correct or does the server validation bug get a CVE > assignment anyway? We feel that you are eligible to have a CVE ID for the "server cert validation was a bit naive" issue if you would like to have one. Here, behavior B is the "server cert validation was a bit naive" issue. Behavior A is "the client is known to accept one blatantly fake server certificate." However, there might be scenarios in which behavior A is intended. For example, maybe an organization has unusual requirements that are well addressed by the "ssl_bump client-first" choice. In particular, the organization physically disconnects all untrusted systems, as well as the external network connection, at a time when the client accepts the fake certificate, thereby ensuring that the client is using an expected fake certificate. The client users are trained to accept fake certificates at that instant of time, and at no other times. The client users are, however, relying on Squid to do proper server cert validation at all times. If Squid is not doing proper server cert validation, then you can report that as a Squid vulnerability and have a CVE ID. Should we proceed with sending that CVE ID? The different scenario that you may have been recalling involves a "behavior A" that could not ever be intended. For example, suppose that a backend server can supply a crafted HTTP response header that causes Squid to download and install a cryptography library from an arbitrary untrusted location. Because the attacker can control this library, server cert validation can be spoofed. (If the usual library is installed, server cert validation can't be spoofed.) Here, there can't be a separate CVE ID for a server cert validation problem: that problem could never stand on its own as independently relevant, and could never be independently fixed. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJVQUpyAAoJEKllVAevmvmsNaIIAL9YuZKuTrX6VKgyYrL/5Dlc Oak7xGprYhxqCy4YDg3qQv6NMCJbMwLvMboQ//s22jE7xBJSYxfBz4E6m3hGg32X 3da6N+SoCbjtFSulucyVNILE4N5wfS2Jad1aNZgmbnZn/xuxJWBcTPzUYcITVXIG DWHfpp9ebjaMUrDZyFLkpJaGOdXTbEGvQSyVmlt2h8eL/5lUEGRYuaUWkvTjL6qG qZAJPz9TnyNHOxtJ/nZ7tRmmJDyXeXubRZlkB3/9aLLjMABgCxZWFStsPs0zN2Ap 6FHrghIed28FBn2vkH4ShG8z65rs8Y7GtKM9ojxEyA1KwpDFO01ZKRXAiZb2hL0= =5f0Z -----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