[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 29 Jan 2015 09:18:32 -0500 (EST)
From: cve-assign@...re.org
To: thoger@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request - ICU
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> 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?
36801 says "Improved checking of regular expression pattern size
limits," and "Improved" doesn't necessarily imply a specific number of
CVEs.
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).
The new RegexTest::TestBug11371 function mentions:
// Pattern with too much string data, such that string indexes overflow operand data field size
// in compiled instruction.
which might imply that at least one overflow attack was possible
against the unpatched code.
Other parts of 36801 mention both:
Append a new instruction onto the compiled pattern.
Includes error checking, limiting the size of the
pattern to lengths that can be represented in the
24 bit operand field of an instruction.
and
Allocate space in the back-tracking stack frame.
Return the index for the newly allocated data.
The frame indexes are inserted into various
opcodes while compiling the pattern, meaning that frame
size must be restricted to the size that will fit
as an operand (24 bits).
If the unpatched code allowed overflow attacks against both the
pattern and the back-tracking stack frame, then these would be
combined into one CVE if the flaw types were the same.
However, 36801 might also have other changes (possibly related to the
new RegexCompile::allocateData function) that are intended to address
complexity problems and not intended to address overflows.
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?
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJUykBsAAoJEKllVAevmvms6ZsIAMepafrfQtfJFKET4m5wz+1Q
IQeMZCBv2nqoToyNfSOcaOPnx567rAhTsIPEgugOW9Oc3A0FgIYCgqLQqIvD4Aog
rBsgV1I7BZ0Uol/ucZHnccLGQZtfm8cPYZTbpHm/LD2pTwV2uVv6Oo5X9pukNTAx
dFRPg4MdzpxaXeEnCt8oXixC9ekivJLk/XT7eZUKmiZo+7gQa1qsDZweymVMqn5f
KkB3cHBu6YMZ1g9qodtif7qZf5kszQvp5JWKVpopBt1M0gngYGKJyHJIr9ciU/AM
KqVAWxoHXgySDOS8fMyfsjjQArbcf1G+yzC9BoGxMNyvgsJ8pIceWauBnLH96/8=
=s1KV
-----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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
