[pcre-dev] [Bug 2330] New: Content "n\xff=" can crash libpcr…

Góra strony
Delete this message
Autor: admin
Data:  
Dla: pcre-dev
Temat: [pcre-dev] [Bug 2330] New: Content "n\xff=" can crash libpcre when an application is matching the pattern \s*=
https://bugs.exim.org/show_bug.cgi?id=2330

            Bug ID: 2330
           Summary: Content "n\xff=" can crash libpcre when an application
                    is matching the pattern \s*=
           Product: PCRE
           Version: 8.39
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: security
          Priority: medium
         Component: Code
          Assignee: ph10@???
          Reporter: kyamiyu@???
                CC: pcre-dev@???


Created attachment 1141
--> https://bugs.exim.org/attachment.cgi?id=1141&action=edit
PoC and steps to reproduce

Hello,

Content "n\xff=" can crash libpcre when an application is matching the pattern
\s*=
The crash happens on latest Ubuntu 18.04 amd64 (libpcre.so.3.13.3 ver 8.39-9 ?
https://packages.ubuntu.com/bionic/libpcre3 ) as of 2018/10/17

Background:
While fuzzing USB Mass Storage on latest Ubuntu, we found that the following
content in the "autorun.inf" file would crash GNOME
(gvfs-udisks2-volume-monitor) on latest Ubuntu release

$xxd autorun.inf
------------------------------------------------------------
00000000: 6963 6f6e fa3d                           icon.=
------------------------------------------------------------


We tracked the bug down to the following lines in
https://gitlab.gnome.org/GNOME/gvfs/blob/master/common/gvfsmountinfo.c

------------------------------------------------------------------------------------------------------------------------
icon_regex = g_regex_new ("icon\\s*=\\s*+([^,\\r\\n]+)",
G_REGEX_CASELESS, 0, NULL);

g_regex_match (icon_regex, content, 0,
 &match_info);
     <----  crashes here
------------------------------------------------------------------------------------------------------------------------


Therefore, the autorun.inf content "icon\xfa=" triggers a crash when gvfs
searches for the pattern "icon\\s*=\\s*+([^,\\r\\n]+)" in it.
Latest Ubuntu is using libpcre.so.3.13.3 for the regex. We created a simple PoC
where we show that an application using the following pattern:

------------------------------------------------------------------------------------------------------------------------
\s*=
------------------------------------------------------------------------------------------------------------------------

Can be crashed by the following content

------------------------------------------------------------------------------------------------------------------------
00000000: 6eff 3d                                  n.=
------------------------------------------------------------------------------------------------------------------------
where the second byte (0xff) can take any value between 0xf7 and 0xff.


The crash seems to happen in the "match" function of libpcre.

We believe the regex pattern \s*= is fairly common, and that the bug could be
used to remotely DoS applications using it.
There are also some similar CVE already reported (e.g.
https://www.cvedetails.com/cve/CVE-2017-7186/).
Therefore we think this might be a security issue.

Please find the PoC and steps to reproduce in the attached file.

Bug information:

libpcre.so.3.13.3
(Linux version 4.15.0-36-generic (buildd@lgw01-amd64-031) (gcc version 7.3.0
(Ubuntu 7.3.0-16ubuntu3)) #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018)
------------------------------------------------------------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7477f86 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#0 0x00007ffff7477f86 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
#1 0x00007ffff74870a1 in pcre_exec () from /lib/x86_64-linux-gnu/libpcre.so.3
#2 0x00007ffff7b1dd3b in g_match_info_next () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff7b1f5cf in g_regex_match_full () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff7b1f71a in g_regex_match () from
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x0000555555554c65 in main ()

(gdb) x/20i $rip-0x20
   0x7ffff7477f66:      jbe    0x7ffff7477f16
   0x7ffff7477f68:      add    al,0x0
   0x7ffff7477f6a:      mov    eax,ecx
   0x7ffff7477f6c:      lea    r11,[rip+0x3cb6d]        # 0x7ffff74b4ae0
   0x7ffff7477f73:      sar    eax,0x7
   0x7ffff7477f76:      lea    r9,[rip+0x4d063]        # 0x7ffff74c4fe0
   0x7ffff7477f7d:      lea    rdi,[rip+0x3c8fc]        # 0x7ffff74b4880
   0x7ffff7477f84:      cdqe
=> 0x7ffff7477f86:      movzx  eax,BYTE PTR [r10+rax*1]
   0x7ffff7477f8b:      shl    eax,0x7
   0x7ffff7477f8e:      mov    edx,eax
   0x7ffff7477f90:      mov    eax,ecx
   0x7ffff7477f92:      and    eax,0x7f
   0x7ffff7477f95:      add    eax,edx
   0x7ffff7477f97:      cdqe
   0x7ffff7477f99:      movzx  eax,WORD PTR [r11+rax*2]
   0x7ffff7477f9e:      movzx  eax,BYTE PTR [r9+rax*8+0x1]
   0x7ffff7477fa4:      cmp    DWORD PTR [rdi+rax*4],0x6
   0x7ffff7477fa8:      sete   al
   0x7ffff7477fab:      movzx  eax,al


(gdb) i r
rax            0xfa0000 16384000
rbx            0x55555575f2c1   93824994374337
rcx            0x7d000000       2097152000
rdx            0x7d000000       2097152000
rsi            0x6      6
rdi            0x7ffff74b4880   140737342294144
rbp            0x55555575df80   0x55555575df80
rsp            0x7fffffffdf00   0x7fffffffdf00
r8             0x55555575f2c3   93824994374339
r9             0x7ffff74c4fe0   140737342361568
r10            0x7ffff74c2de0   140737342352864
r11            0x7ffff74b4ae0   140737342294752
r12            0x1      1
r13            0x0      0
r14            0x55555575f2c1   93824994374337
r15            0x7ffff74b4a20   140737342294560
rip            0x7ffff7477f86   0x7ffff7477f86
eflags         0x10206  [ PF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0


Crashes happens at 0x7ffff7477f86:      movzx  eax,BYTE PTR [r10+rax*1]   
Although it says "??", we think the location is match+0x3546


rax content is influenced by the second byte
0xf7 -> rax            0x8b8b
0xf8 -> rax            0x1e800
0xf9 -> rax            0x3e800
0xfa -> rax            0x5e800
0xff -> rax            0xfa0000


and r10 is a pointer to an array of increasing bytes

(gdb) x/200bx $r10
0x7ffff74c2de0: 0x00    0x01    0x02    0x03    0x04    0x05    0x06    0x07
0x7ffff74c2de8: 0x08    0x09    0x0a    0x0b    0x0c    0x0d    0x0e    0x0f
0x7ffff74c2df0: 0x10    0x11    0x12    0x13    0x14    0x15    0x16    0x17
0x7ffff74c2df8: 0x18    0x19    0x1a    0x1b    0x1c    0x1d    0x1e    0x1f
0x7ffff74c2e00: 0x20    0x21    0x22    0x23    0x24    0x25    0x26    0x27
0x7ffff74c2e08: 0x28    0x29    0x29    0x29    0x2a    0x2b    0x2c    0x2d
0x7ffff74c2e10: 0x2e    0x2f    0x30    0x31    0x32    0x33    0x34    0x35
0x7ffff74c2e18: 0x36    0x37    0x38    0x39    0x3a    0x3b    0x3c    0x3d
0x7ffff74c2e20: 0x3e    0x3f    0x40    0x41    0x42    0x42    0x43    0x44
0x7ffff74c2e28: 0x45    0x46    0x47    0x48    0x49    0x47    0x4a    0x4b
0x7ffff74c2e30: 0x4c    0x4c    0x42    0x4d    0x42    0x42    0x4e    0x4f
0x7ffff74c2e38: 0x50    0x51    0x52    0x53    0x54    0x55    0x56    0x57
0x7ffff74c2e40: 0x58    0x59    0x5a    0x5b    0x5c    0x5d    0x5e    0x47
0x7ffff74c2e48: 0x5f    0x5f    0x5f    0x5f    0x5f    0x5f    0x5f    0x5f
0x7ffff74c2e50: 0x5f    0x5f    0x5f    0x5f    0x5f    0x5f    0x5f    0x5f
0x7ffff74c2e58: 0x5f    0x5f    0x5f    0x5f    0x5f    0x5f    0x5f    0x5f


------------------------------------------------------------------------------------------------------------------------

Best regards,
Camille Gay

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