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.
