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

Hash: SHA256

> atleast 3 issues in here which are CVE worthy
> 1. Heap based buffer overflow:
> 2. Fix hmtx wrong table length check:
> 3. heap-buffer-overflow in hb_ot_face_metrics_accelerator_t::get_advance

As far as we can tell, these correspond to:

1 -
    fixed in 1.0.5

2 -
    fixed in 1.0.6

3 -
    the unpatched code is not in any release; the patched code is new in 1.1.0

df698f3299d92867e3305715f675b2621c316acd mentions "I rewrote the table
checking yesterday ... and introduced the exact same issue again." Is
there a particular motivation for having a CVE ID? We don't know of
anyone who is shipping products based on unreleased HarfBuzz code
obtained from GitHub, and the one-day existence of the problematic
code also seems to suggest minimal real-world relevance. The HarfBuzz
documentation doesn't specifically recommend that people ship
unreleased HarfBuzz code. A CVE ID isn't, in general, required for
each issue noted at any arbitrary point during development.

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

> how does
> MITRE plan to handle vendors who assign one CVE to multiple non-related
> issues?

Anyone is free to submit new CVE ID requests with sufficient
information to show that additional IDs are required. Typically this
means that the requester should, for example, track down all of the
upstream version information.

In general, it is not realistic to expect that the "multiple
non-related issues" case can be completely eliminated when CVE IDs
are originally assigned. When product A repackages code from product
B, there can be a disparity in whether the B maintainers are as
interested in CVE as the A maintainers. Also, the A maintainers do not
necessarily have any motivation for investigating the precise details
of what was fixed in B, unless the A maintainers are backporting
patches. For example, A might just be updating to the latest version
of B, because the B Release Notes stated that it was a security
update. Suppose that the A maintainers confirm that the B maintainers
have not been, and will not be, using CVE IDs themselves. Would it be
better for the A maintainers to use one CVE ID immediately, or should
everyone wait (potentially forever) for someone to investigate the
precise details?

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