[pcre-dev] [Bug 1653] New: Security issue: Overwriting stack…

トップ ページ
このメッセージを削除
著者: admin
日付:  
To: pcre-dev
題目: [pcre-dev] [Bug 1653] New: Security issue: Overwriting stack content from JIT
https://bugs.exim.org/show_bug.cgi?id=1653

            Bug ID: 1653
           Summary: Security issue: Overwriting stack content from JIT
           Product: PCRE
           Version: 10.10 (PCRE2)
          Hardware: x86
                OS: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: hzmester@???
                CC: pcre-dev@???


Hi,

I have been working on optimization lately, and I found a serious security
issue in JIT.

In set_private_data_ptrs() function:

if (private_data_ptr > SLJIT_MAX_LOCAL_SIZE)
    return;  // This should be changed to break;


This function computes the stack scape for the compiled function, and returns
with an error if there is not enough space. Unfortunately it only returns at
the moment, but it does not report anything back. The compilation continues,
and the resulting code allocates only a small stack, but overwrites things
outside of thsi stack.

With a well crafted pattern, it allows executing any code. Namely:

/a*a*a*a*a*a*a*a*a*(*COMMIT)(*FAIL)|b*b*b*b*...b*/

We need a lots of b*, around 9000 is enough even on 32 bit systems. These b*-s
are just dummy stuff to increase stack size, they are never executed. If they
would be executed, we might write data outside the starting position of the
stack, resulting a segmentation fault. We want to execute code now, not just
crash the program.

If a* does not match, it puts the starting position of the input twice onto the
stack. Since the function return value is overwritten, the JIT code will return
to the starting offset of the input string (i.e. the string the pattern is
matched against). If the input string contains valid machine code, we can do
bad things. The input string should not start with 'a'. If it is, just change
a* to b*.

This code was introduced in r1306 (2013-04-01). It affects both PCRE/PCRE2 (but
not the upcoming PCRE2 release).

I am sorry for this unfortunate check. Here is a fix:

https://lists.exim.org/lurker/message/20150628.133124.e06b7a2c.en.html

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