oss-sec mailing list archives
Re: Re: CVE request - ICU
From: Tomas Hoger <thoger () redhat com>
Date: Thu, 29 Jan 2015 21:41:25 +0100
On Thu, 29 Jan 2015 09:18:32 -0500 (EST) cve-assign () mitre org wrote:
https://code.google.com/p/chromium/issues/detail?id=432209 https://chromium.googlesource.com/chromium/deps/icu/+/dd727641e190d60e4593bcb3a35c7f51eb4925c5 http://bugs.icu-project.org/trac/changeset/36801Do you believe there's enough information available to determine how many CVEs should exist that are specific to Chromium bug 432209?
...
The utypes.h change mentions: U_REGEX_PATTERN_TOO_BIG, /**< Pattern exceeds limits on size or complexity. @draft ICU 55 */ In some cases in various products, a length fix is motivated by an overflow or overflows, which would have one CVE, and a complexity fix is motivated by a desire to restrict a resource-consumption attack, which might have its own CVE (but, in any case, would not be the same as the overflow CVE).
I do not have access to either of the private upstream bugs to know if any resource consumption attacks are mentioned there. My understanding is that the fix aims to ensure that lengths / operands / indexes do not exceed 2^24. I'm guessing, but complexity may refer to exceeding the limit with short patterns as well. This issue was fixed in the same Chrome update (CVE-2014-7923 or CVE-2014-7926), short patterns cause generation of invalid opcodes because of operands exceeding 2^24: http://bugs.icu-project.org/trac/changeset/36724 https://chromium.googlesource.com/chromium/deps/icu/+/3af4ce5982311035e5f36803d547c0befa576c8c
This leads to a possibility of these two observations: A. the entire known vulnerability is that the unpatched code calculates certain values without ensuring that they can be represented in a 24-bit field B. the vendor has not stated whether there is a vulnerability related solely to the concept of complexity. Possibly part of 36801 addresses complexity as a security-hardening measure, not a vulnerability fix. Or, possibly nothing in 36801 is exclusively about complexity. Should there be one CVE ID now, for observation A alone?
That's what can be done based on the information public at the moment. This may not be perfect, but still significant improvement from having this grouped with 30+ other, likely unrelated, issues under single CVE. -- Tomas Hoger / Red Hat Product Security
Current thread:
- CVE request - ICU Tomas Hoger (Jan 28)
- Re: CVE request - ICU cve-assign (Jan 29)
- Re: Re: CVE request - ICU Tomas Hoger (Jan 29)
- Re: CVE request - ICU cve-assign (Feb 05)
- Re: Re: CVE request - ICU Tomas Hoger (Jan 29)
- Re: CVE request - ICU cve-assign (Jan 29)