9月23日发布Windows Server修补程序漏洞（CVE-2019-1367）之后
已更新07.10.2019 另外，“月度汇总预览”和“月度汇总”软件包也受到影响，无法解决特定的Jscript工作流问题
在经典的ASP应用程序中，发生了几种工作流情况jscript服务器端出现了意外错误：
远程执行代码漏洞以 脚本引擎处理Internet Explorer中的内存中的对象 “脚本引擎内存损坏漏洞”。此CVE ID为 从CVE-2019-1221。 https://www.cvedetails.com/cve/CVE-2019-1367/
远程执行代码漏洞以 脚本引擎处理Internet Explorer中内存中的对象。的 漏洞可能以一种攻击者的方式破坏内存 可以在当前用户的上下文中运行任意代码。一个 成功利用此漏洞的攻击者可以获得 与当前用户相同的用户权限。在基于Web的攻击情形中， 攻击者可能拥有一个旨在 通过Internet Explorer利用该漏洞，然后说服 用户例如通过发送电子邮件来查看网站。的 此安全更新通过修改 脚本引擎处理内存中的对象。 https://blog.qualys.com/laws-of-vulnerabilities/2019/09/24/microsoft-releases-out-of-band-security-updates
据说补丁可以解决内存管理中的问题。没有指定确切的更改，新的限制。但这似乎会导致一些副作用失败案例。
已验证该补丁程序在所有经过测试的Server实例上均存在该问题。还通过检查应用补丁之前和之后的状态来隔离补丁（Server 2012 R2，Server 2016，Windows 10-1809）
关于
的异常环境
已确定的问题
msvcrt上的指令！memcpy + 198 ### Microsoft Corporation的C：\ Windows \ System32 \ msvcrt.dll中的错误导致访问 尝试从线程33上的内存位置0x0000000a读取时发生冲突异常（0xC0000005） 指令地址 来源
[0x7532a2d8] msvcrt!memcpy+198
[0x6ac17deb] jscript!AString::CopyToBuffer+4b
[0x6ac10524] jscript!AString::ConvertToBSTR+1bb74
[0x6abdf6b7] jscript!PrepareInvoke+277
[0x6abf52df] jscript!InvokeDispatch+8f
[0x6abe2f03] jscript!VAR::InvokeByDispID+523
[0x6abdbde0] jscript!NameTbl::InvokeInternal+270
[0x6abe2b17] jscript!VAR::InvokeByDispID+137
[0x6abe6083] jscript!CScriptRuntime::Run+2db3
...
后跟-Microsoft Corporation尝试从内存位置0x00000000读取时导致访问冲突异常（0xC0000005）
[0x6b7c2d77] jscript!VarStack::ScavengeRoots+27
[0x6b7c2b89] jscript!GcContext::CollectCore+79
[0x6b7c2af4] jscript!GcContext::Collect+1b
[0x6b7bca21] jscript!GcContext::ExhaustiveCollect+21
[0x6b7a604a] jscript!CSession::Close+18a
[0x6b7a32d9] jscript!COleScript::CloseInternal+13b
[0x6b7a2d36] jscript!COleScript::Close+16
[0x6b8a71ce] asp!CActiveScriptEngine::FinalRelease+1be
...
未确定导致问题的确切行，FailedRequestTrace的最后一条记录是从Application Scope xml对象属性分配字符串变量。 （CurrentStatement返回attrib.text）
类似情况-尝试从内存位置0x00000000读取时发生访问冲突异常（0xC0000005）
[0x6b907e09] jscript!AString::CopyToBuffer+69
[0x6b900524] jscript!AString::ConvertToBSTR+1bb74
[0x6b8e49a7] jscript!VAR::ConvertASTRtoBSTR+13
[0x6b8c49e8] jscript!VAR::GetValue+58
[0x6b8e0f34] jscript!ConvertToString+58
[0x6b922fbf] jscript!JsString+4f
[0x6b8d92e6] jscript!NatFncObj::Call+e6
...
后跟-尝试从内存位置0x004e0049读取时发生访问冲突异常（0xC0000005）
[0x6b8e2d77] jscript!VarStack::ScavengeRoots+27
[0x6b8e2b89] jscript!GcContext::CollectCore+79
[0x6b8e2af4] jscript!GcContext::Collect+1b
[0x6b8dca21] jscript!GcContext::ExhaustiveCollect+21
[0x6b8c604a] jscript!CSession::Close+18a
[0x6b8c32d9] jscript!COleScript::CloseInternal+13b
[0x6b8c2d36] jscript!COleScript::Close+16
[0x6bfb71ce] asp!CActiveScriptEngine::FinalRelease+1be
...
导致访问冲突异常（0xC0000005）
[0x6f042e88] asp!CResponseBuffer::Write+3a
[0x6f0452ea] asp!CResponse::WriteSz+4c
[0x6f02dd3b] asp!CErrInfo::LogErrortoBrowser+ff
[0x6f02d4c9] asp!CErrInfo::LogErrortoBrowserWrapper+d7
[0x6f02d047] asp!CErrInfo::LogError+e8
[0x6f02e241] asp!HandleError+116
[0x6f02f009] asp!HandleErrorMissingFilename+df
[0x6f04941b] asp!CActiveScriptEngine::Call+bb
[0x6f030eff] asp!CallScriptFunctionOfEngine+4d
[0x6f02f99f] asp!ExecuteRequest+173
[0x6f02f828] asp!Execute+23d
[0x6f035c6f] asp!CHitObj::ViperAsyncCallback+467
[0x6f05df53] asp!CViperAsyncRequest::OnCall+73
[0x6eefd325] comsvcs!CSTAActivityWork::STAActivityWorkHelper+45
[0x77098346] combase!EnterForCallback+16e [onecore\com\combase\dcomrem\crossctx.cxx @ 2072 + 2] onecore\com\combase\dcomrem\crossctx.cxx @ 2072 + 2
[0x7709816d] combase!SwitchForCallback+206 [onecore\com\combase\dcomrem\crossctx.cxx @ 1694] onecore\com\combase\dcomrem\crossctx.cxx @ 1694
[0x7709bae4] combase!PerformCallback+bc [onecore\com\combase\dcomrem\crossctx.cxx @ 1573 + 16] onecore\com\combase\dcomrem\crossctx.cxx @ 1573 + 16
[0x7709b7f9] combase!CObjectContext::InternalContextCallback+119 [onecore\com\combase\dcomrem\context.cxx @ 4421 + 1a] onecore\com\combase\dcomrem\context.cxx @ 4421 + 1a
[0x77198e66] combase!CObjectContext::DoCallback+26 [onecore\com\combase\dcomrem\context.cxx @ 4254] onecore\com\combase\dcomrem\context.cxx @ 4254
[0x6eefd015] comsvcs!CSTAActivityWork::DoWork+175
[0x6eeff0e0] comsvcs!CSTAThread::DoWork+26
[0x6eeff599] comsvcs!CSTAThread::ProcessQueueWork+48
[0x6eeff8dd] comsvcs!CSTAThread::WorkerLoop+13d
[0x76577e71] msvcrt!_callthreadstartex+25
[0x76577f31] msvcrt!_threadstartex+61
[0x765f0419] kernel32!BaseThreadInitThunk+19
[0x77d5662d] ntdll!__RtlUserThreadStart+2f
[0x77d565fd] ntdll!_RtlUserThreadStart+1b
...
最有可能来自写入日志文件
ioo_fso = Server.CreateObject（“ Scripting.FileSystemObject”）; ... loo_file = loo_fso.OpenTextFile（ls_filename，8，true）; ... 尝试{ loo_file.WriteLine（“ [” + str +“]”）} catch（ee）{}
过程监视器在访问日志文件时显示w3wp.exe的“共享违规”日志记录
var pbkdf2;
try {
pbkdf2 = Server.CreateObject("Pbkdf2");
pbkdf2.hashPassword(ls_newpassword, 100000);
} catch (e) {
addToLogg("Login:CreateObject failed for Pbkdf2, " + e.description);
}
来自FailedReqLogFiles日志，但尚未在DebugDiag中标识
我知道ASP Jscript是一种过时的，过时的技术，但是应该仍然有大量的Enterprise解决方案，因此可能有人会遇到这些问题。 我希望Jscript定期出现，以便可以处理错误情况
如@Max所示（最后），最后一个Microsoft KB修复了Jscript工作流问题。
解决了利用以下问题的应用程序和打印机驱动程序的问题 Windows JavaScript引擎（jscript.dll）来处理打印作业。
显然，常见的jscript处理中的修复程序
解决问题的知识库摘要
不需要卸载以前的KB更新。 安装新版本后，请参阅“窗口更新”中不再存在以前的每月汇总（10月3日）。
虽然我没有设法从工作流程中隔离主要的“首次机会异常0xC0000005”：
答案 0 :(得分：2)
我们还遇到了与CVE-2019-1367和经典ASP相关的相同错误。我们将错误的范围缩小到了我们使用JScript而不是VBScript进行JSON转换的几个地方，然后将其进一步缩小到了使用regex的地方。我们通过重写VBScript中的JScript代码中的功能来解决这些错误。
我发现this article指的是CVE-2019-13670，其数字非常相似，措辞也非常相似： Google Chrome浏览器可能允许远程攻击者在系统上执行由V8引起的任意代码正则表达式中的内存损坏。。
CVE-2019-1367特定于Internet Explorer，并且已更新C\Windows\system32\JScript.dll。由此，我猜测IE的javascript引擎和经典的ASP JScript引擎都由JScript.dll处理？胡乱猜测。 CVE-2019-13670是特定于Chrome的（我认为它不使用JScript.dll），但它提到了regex，我们发现我们的问题专门针对JScript中的正则表达式使用。
答案 1 :(得分：0)
我的小组也遇到了这些问题。我们整个遗留系统都是用ASP编写的 使用JScript。 KB4522007更新已于2019-09-25安装，这时我们注意到了错误。除了原始帖子中提到的错误之外，我们还遇到其他错误：
这些都是未修改文件中发生的所有错误，在更新之前从未观察到。错误是周期性的，不能系统地再现...
删除更新的KB4522007导致错误消失。
答案 2 :(得分：0)
Microsoft的最新更新似乎可以解决该问题。