Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 19 Jul 2016 00:57:07 -0400 (EDT)
Subject: Re: CVE Requests: HarfBuzz - Chromium CVE issues

Hash: SHA256

>> Would it be OK to keep CVE-2016-2052 for
>> 63ef0b41dc48d6112d1918c1b1de9de8ea90adb5 (which is really a "before
>> 1.0.6" issue as stated in that CVE), and assign one new ID for
>> f96664974774bfeb237a7274f512f64aaafb201e (the "before 1.0.5" issue)?

> Sure, i dont mind as long as its communicated well etc!

f96664974774bfeb237a7274f512f64aaafb201e is now CVE-2015-8947. We
will also communicate this at within
about a day or two.

> This means that, if you dont have motivation for investigating the
> individual issues, it is ok to assign CVEs to multiple unrelated issues?
> It so, that means everyone is free to do the above mentioned.

Not everyone is free to do it: the decision belongs to whoever is
responsible for assigning CVE IDs to that product at that point in
time. Keep in mind that no one is forcing Google to have a public bug
report stating "Update harfbuzz to 1.0.6 ... There are a few security
bugs fixed between 1.0.5 and 1.0.6." Google could have decided to
announce only that "we occasionally update Chrome's components to the
latest upstream version for any reason or no reason." Because that
public bug report existed, it gave MITRE the opportunity to put a
HarfBuzz entry into the CVE corpus. This is presumably of some value
to other vendors that ship HarfBuzz, even though it is not optimal.
The information readily available to us was that the product name was
HarfBuzz, the vulnerable version was 1.0.5, the fixed version was
1.0.6, and the type of problem was denial of service. Going beyond
that requires expensive analysis, given that HarfBuzz issue 139 is
described as "This in an umbrella issue for setting up regular fuzzing
for harfbuzz and fixing the bugs that we find with fuzzing." The
earlier portion of this thread indicates that you contributed
significant analysis effort to report "i realized that there are
atleast 3 issues in here which are CVE worthy," and yet one of the
cited issues was about unreleased code that was corrected during the
development cycle within one day.

This is not solely a question of whether a third party has motivation
to do some analysis: it is also a question of whether it is typically
feasible for third parties to understand everything. Ultimately, it
would work better if the direct developers of the code recognized
value in CVE, and made the CVE requests and/or assignments themselves.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


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.