Date: Sun, 17 Jul 2016 16:00:08 -0400 (EDT) From: cve-assign@...re.org To: huzaifas@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Requests: HarfBuzz - Chromium CVE issues -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > atleast 3 issues in here which are CVE worthy > > 1. Heap based buffer overflow: > https://github.com/behdad/harfbuzz/issues/139#issuecomment-146984679 > > 2. Fix hmtx wrong table length check: > https://github.com/behdad/harfbuzz/issues/139#issuecomment-148289957 > > 3. heap-buffer-overflow in hb_ot_face_metrics_accelerator_t::get_advance > https://github.com/behdad/harfbuzz/issues/156 As far as we can tell, these correspond to: 1 - https://github.com/behdad/harfbuzz/commit/f96664974774bfeb237a7274f512f64aaafb201e fixed in 1.0.5 2 - https://github.com/behdad/harfbuzz/commit/63ef0b41dc48d6112d1918c1b1de9de8ea90adb5 fixed in 1.0.6 3 - https://github.com/behdad/harfbuzz/commit/df698f3299d92867e3305715f675b2621c316acd 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 http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXi+MCAAoJEHb/MwWLVhi2wgAQAJLXVA40PHjC/4BOS7shFg+L XuoF2XzKGCh76iqAw0ZJK4ID6vRLfrn82hxFZfNqBm1K22QCVXk8Mg2m4NKkWMtf ukfNCaBoZaV66+YHJkCoVuADfkvfOtzCjh0KZef1f6pPboH9T0h6MuUK3Tj377Yg b3JE0Lo3uOWEWqNvd5l4abyIBksKfRhbqCaMm7PvPqWnlAm6klPs3CXgdGOmuZH1 o/j19BRNIzqVMYSpakeCJABp03gNMdcG2ralIYtMABNbaUVbBEsCyacMhiMTuXn4 Y5Q676tfQFy3fAUPfC0C98qa0YsbiY1DigQtbPx3sVtssL5sOSWdRXfJ7iG7NdV7 4YvVq17R9W2+pDvuZGa8jXXY3rRb3QoWz/RdyqlAGy8Dacgm44+zV7pot0ViM5l8 kHPpVJHQ66ggM4zLMF/Os2Fh+u1KUOf/6EYJhZhMlE/NncJuZWgHzY9KsZelutja FiF3UotH95sSLoCpV12nUKXZaQ8J7X7f54SOK3n6cygFdMnObx1C93/3FUASnay4 e20ZjIs/O++42kmDnd0tpGVP2ZvDFPJ+deUxAtxKL9g3DzyAyvXhGba9g+zgbIB/ KM2dMvlgM1WshMOoOL9x3lS2/wsZkhivxF+Wamg/F7348MXk2C9oJqI57MNsYPGt wGEjdlgK1yth7LE1EIrc =QsMP -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ