Re: Heap Overflow in PCRE

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I have a question about CVE-2015-8384, according to
> https://bugzilla.redhat.com/show_bug.cgi?id=1287623 the fixing commit
> in upstream VCS is r1558, but (cf.
> https://bugzilla.redhat.com/show_bug.cgi?id=1287623#c6) CVE-2015-3210
> was assigned for the issue fixed by the same revision r1558.

We currently plan to keep CVE-2015-3210 and CVE-2015-8384 separate.

We'll try to answer the question in three ways:

1. Different attack methodologies discovered independently can have
separate CVE IDs, even if the fix is the same. We don't know of
any scalable way to reach a conclusion that
/^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/ (which
is CVE-2015-3210) and /(?J)(?'d'(?'d'\g{d}))/ (which is
CVE-2015-8384) are the same attack methodology.

2. https://bugzilla.redhat.com/show_bug.cgi?id=1226918#c9 indicates
that the CVE-2015-3210 attack is prevented by a commit for
"Fix buffer overflow for named recursive back reference."
Our experience is that Red Hat generally has a good process for
locating commits based on the associated bug reports; however,
we sometimes don't know how they reach a specific conclusion.

3. The pattern in question for CVE-2015-3210, i.e., the
/^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/ pattern,
doesn't have any instances of something like \1 or \g that
are commonly used for a back reference. Although we haven't
studied the pattern in detail, we think the attack methodology
is different from the one that has a \g escape sequence.

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

iQIcBAEBCAAGBQJWX3dCAAoJEL54rhJi8gl5xjIP/0aGf7NTUqQsfVMrEjiUb60Z
V93xFSutonq+qg/Ps2Im5FRx32EMEYJXoqS8KpMiUmRZbz1zSwf7caeT+3MpEBTO
m32S5XMa5SKhdOu2X2bDTkxQO062ygCXizSTkl7YgSt+lswnM5ZztTMXybHJtChz
rD7GGsh3OE1LLkTeHb1JEIr3ijnLNNA184Viqxp08APawUxHvCNMGIt0UtdOH7OM
e5aqWP7dEIgX3oZzixK3l64xAD8RPQS9SF71kdRXcHx+GQR1yuM9DqgJd4CIhGY8
XwtOAlctQqxvLD3rA9gSI7G5YPT8+6LMEcXtmk7Ef+CkDEkCUCeQb4FYOHXTeHX4
MoEDcYF3OTOMEcUIiStsBRQZGzEqTsbPK1Qx2NUnTnw7aUhJI2GGXQ8gXYyhX0Vl
zBG3JpiB64LD9BV/QRq/MZUTxPaKGevHtjkMNkU41cUeFDr7i3YVynqywZxZ7dyG
1lwZxKvMUy4xD+RijO5puli7qC6TxntHhU6ICzP1kha2PS9GUbTX93XqK+CYOAAi
jgbNP/LkI2unIOMWoYICC6LvtwBO+nUWlQlb25JucrBFPh4A9ZvLwCBE+k9X4D9d
LybiL8nyT56uM74bz9dQ/qpCguSIo9PVBnLFgedXluK4Sey5OSw8vOy/ZgWBXQKU
E4TXlM/tQ5Sttfio/C8h
=3oE2
-----END PGP SIGNATURE-----