Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 15 Jan 2014 00:46:18 -0500 (EST)
Subject: Re: CVE Request -- libvirt: denial of service with keepalive

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 in the
coming days with a brief explanation and a pointer back to

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:

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 ]
Version: GnuPG v1.4.14 (SunOS)


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.