[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
