[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Re: CVE request - ICU
From:       Tomas Hoger <thoger () redhat ! com>
Date:       2015-01-29 20:41:25
Message-ID: 20150129214125.5ee653dd () redhat ! com
[Download RAW message or body]

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/36801
> 
> Do 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
[prev in list] [next in list] [prev in thread] [next in thread]