oss-sec mailing list archives
Re: Heap Overflow in PCRE
From: cve-assign () mitre org
Date: Wed, 2 Dec 2015 17:59:38 -0500 (EST)
-----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-----
Current thread:
- Re: Heap Overflow in PCRE, (continued)
- Re: Heap Overflow in PCRE Hanno Böck (Nov 24)
- Re: Heap Overflow in PCRE Fabian Keil (Nov 24)
- Re: Heap Overflow in PCRE Hanno Böck (Nov 24)
- Re: Heap Overflow in PCRE Fabian Keil (Nov 25)
- Re: Heap Overflow in PCRE Hanno Böck (Nov 24)
- Re: Heap Overflow in PCRE cve-assign (Nov 28)
- Re: Re: Heap Overflow in PCRE Michal Zalewski (Nov 28)
- Re: Heap Overflow in PCRE cve-assign (Nov 29)
- Re: Re: Heap Overflow in PCRE Tomas Hoger (Nov 30)
- Re: Re: Heap Overflow in PCRE Michal Zalewski (Nov 28)
- Re: Heap Overflow in PCRE cve-assign (Dec 01)
- Re: Re: Heap Overflow in PCRE Salvatore Bonaccorso (Dec 02)
- Re: Heap Overflow in PCRE cve-assign (Dec 02)
- Re: Re: Heap Overflow in PCRE Jakub Wilk (Dec 03)