Microsoft补丁CVE-2019-1367之后出现错误“ ASP 0115发生了可陷阱错误”

问题描述投票：2回答：1

Jscript意外异常

[9月23日发布Windows Server修补程序漏洞（CVE-2019-1367）之后

Windows Server 2019（KB4522015）https://support.microsoft.com/en-us/help/4522015/windows-10-update-kb4522015
Windows Server 2016（KB4522010）
基于x64的系统的Windows Server 2008 R2 Service Pack 1（KB4522007）
Windows Server 2012（KB4522007）
Windows Server 2012 R2（KB4522007）

已更新07.10.2019另外，“月度汇总预览”和“月度汇总”软件包也受到影响，无法解决特定的Jscript工作流问题

Windows Server 2019：KB4516077，KB4524148
Windows Server 2016：KB4516061，KB4524152
Windows Server 2012 R2：KB4516041，KB4524156

在几个工作流案例中的经典ASP应用程序中，正在发生jscript服务器端发生意外错误：

Active Server Pages错误'ASP 0115'
外部对象中发生可捕获错误（C0000005）。脚本无法继续运行
Active Server Pages错误'ASP 0240'
ScriptEngine在'IActiveScript :: Close（）'中从'CActiveScriptEngine :: FinalRelease（）'引发了异常'C0000005'。

补丁

一个远程执行代码漏洞以脚本引擎处理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

据说该补丁解决了内存管理中的问题。没有指定确切的更改，新的限制。但似乎会导致一些副作用失败案例。

错误性质

无法通过常规try-catch方法处理错误
错误导致工作流中断
该异常似乎只在进入特定的工作流时发生过一次，并且在对同一例程的重复Web请求中，代码成功（直到重新启动App-pool）。
有时是第一次，第二次或第三次进入工作流程。
仅当IIS ASP调试属性-启用服务器端调试设置为False时，才会发生异常

背景

已验证该补丁程序在所有经过测试的Server实例上均存在该问题。还通过检查应用补丁之前和之后的状态来隔离补丁（Server 2012 R2，Server 2016，Windows 10-1809）

从经典ASP Server无法使用try-catch处理问题，
返回一般错误-脚本错误消息或者关闭（ASP-向浏览器发送错误）ASP错误代码及其出现的页面
事件查看器还注册了这些错误，但没有其他信息
Global.asa不提供全局错误处理，ASP Server对象Server.GetLastError（）没有捕获异常

探索例外

DebugDiag
Sysinternals过程监视器
IIS-请求跟踪失败

环境

[App-Pool：经典管道模式，启用32位应用程序：True
应用程序：ASP
ClientL IE 11企业模式，启用了ActiveX
应用程序池标识在Web请求调用中被模拟

已确定的问题

1在w3wpV ...第一次机会异常0XC0000005.dmp程序集中

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
...
2在w3wp __...__ Second_Chance_Exception_C0000005.dmp中，汇编指令位于asp！CResponseBuffer :: Write + 3a
来自Microsoft Corporation的\？\ C：\ Windows \ System32 \ inetsrv \ asp.dll在尝试从线程32的内存位置0x00000014读取时导致访问冲突异常（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的“共享违规”日志记录

3在自定义服务器自定义组件创建之后也经历了ASP 0115 ###

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定期下降，以便可以处理错误情况

其他人也遇到过类似情况吗？
对jscript代码的新限制是什么？
在将响应返回给客户端之前，是否有方法可以在服务器端处理这些失败？
也许有一些ASP / jscript环境设置，内存管理设置，Windows特权，权限可以潜在地解决问题？

[Jscript Windows Server修补程序漏洞（CVE-2019-1367）在23月9月发布之后出现意外异常（KB4522015）https：//support.microsoft.com/zh-cn/help/4522015 / ...] >

我们还遇到了与CVE-2019-1367和经典ASP相关的相同错误。我们将错误的范围缩小到了我们使用JScript而不是VBScript进行JSON转换的几个地方，然后将其进一步缩小到了我们使用regex的地方。我们通过重写VBScript中JScript代码中的功能来解决这些错误。

[我发现this article指的是CVE-2019-13670，具有非常相似的数字和非常相似的措词： >。

CVE-2019-1367特定于Internet Explorer，并已更新C\Windows\system32\JScript.dll。由此，我猜想IE的javascript引擎和经典的ASP JScript引擎都由JScript.dll处理？胡乱猜测。 CVE-2019-13670是特定于Chrome的（我认为它不使用JScript.dll），但它提到了regex，我们发现我们的问题专门针对JScript中的正则表达式使用。

asp-classic jscript

1个回答

2
投票

我们还遇到了与CVE-2019-1367和经典ASP相关的相同错误。我们将错误的范围缩小到了我们使用JScript而不是VBScript进行JSON转换的几个地方，然后将其进一步缩小到了我们使用regex的地方。我们通过重写VBScript中JScript代码中的功能来解决这些错误。

[我发现this article指的是CVE-2019-13670，具有非常相似的数字和非常相似的措词： >。

最新问题

© www.soinside.com 2019 - 2024. All rights reserved.