Re: CVE Request -- libvirt: denial of service with keepalive

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks very much for the additional information about your release
process. In this situation, the cost of having two CVEs outweighs any
possible benefit, so we've proceeded to make the change to a single
CVE as follows:

> Use CVE-2014-1447 for this issue in which the product does not check
> whether the connection is still open. This corresponds to
> 173c2914734eb5c32df6d35a82bf503e12261bcf, which apparently would be of
> some value in some attack scenarios.

> Use CVE-2014-1448 for this issue in which the product does not
> properly check whether the connection is still open. This corresponds
> to 066c8ef6c18bc1faf8b3e10787b39796a7a06cc0, which apparently is of
> value in additional attack scenarios.

Both of these issues are now within the scope of CVE-2014-1447.
CVE-2014-1448 has been REJECTed - it will appear at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1448 in the
coming days with a brief explanation and a pointer back to
CVE-2014-1447.


We wanted to clarify one point about CVE assignment by MITRE. The
comments mentioned "Neither of those versions is released" and "the
hourly builds are NOT supported releases." The guidance we currently
provide to our CVE Numbering Authority participants is that
assignments should only be for vulnerabilities in software that was
"made generally available to the vendor's customers." This guidance
does not include any restrictions on whether a vulnerability's context
is in a release, or on whether any support is offered for
vulnerability remediation. For example, beta software has been
explicitly in scope for the past 14 years.

> GIT snapshots do not count as end user packaged releases - if you were
> to take that view, then every single git commit would have be
> considered a 'package' since gitweb has a link to download a .zip of
> any revision.

The distinction is that downloads.html says "should be usable" but a
gitweb page with a .zip link typically doesn't say that. Admittedly,
the distinction may be practically irrelevant in the specific case of
libvirt-git-snapshot.tar.gz. You understand your customers, but we
don't understand your customers. If a new vulnerability were
introduced in one snapshot and fixed in the next snapshot, you might
have very good information that there's nobody at all who would even
want to track that vulnerability.

One challenge for us is that not all codebases are the same. For this
FFmpeg issue:

   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3670

people might think the CVE is largely useless because no release was
affected. However, some well-known third parties use git snapshots of
FFmpeg. The end result is that the vulnerable code either was shipped
to many, many end users -- or else it was "almost" shipped to those
end users except that a delay caused a sufficiently later snapshot to
be used instead.

- -- 
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)

iQEcBAEBAgAGBQJS1h9WAAoJEKllVAevmvmswG4H/1Q+KlNxMgssyliPDx1J/BgA
ve5UacYKAwcAWG34/mJAm4TvdIgeJ0xZBJU9C9qFfK+fIxQacnOznWBOEEGJ2bw2
UQXakpCfWEM6tjJwCjpOs7Hx1dXQSEXB9y47NqylQHN9xg36XlBwhvjzKSDUmwvi
DfNTvo/yWLa79rFVMgsgyVs7bXBIoNyO7el9lE6rsXHj/jG3aSej++ip2Umuw2MY
wlgW1mrXcw96Fvlp1fOHScaCAItEG86kJ+HiXOz3u01k8w6pUimm6CvbBBlQPvYt
iclq8dALGSfu8iIBrlUz+zyEu7odTXNsdNi8yx9El6jC46ILCJfeotqnF74EVeo=
=2K5m
-----END PGP SIGNATURE-----