CVE-2017-5124 CVE-2017-7089 两个UXSS分析

Chrome 和 Safari 的 UXSS,学习一下

POC:https://github.com/Bo0oM/CVE-2017-5124/blob/master/PoC.mht,

原作者的分析:https://bo0om.ru/chrome-and-safari-uxss

以及一个英文翻译:https://securityespresso.org/translations/2017/11/14/chrome-and-safari-uxss/

作者原文中包含了两个漏洞,分别是 Safari 的 CVE-2017-7089 ,通过 parent-tab:// 伪协议造成的 SOP Bypass,以及 Chrome 的 CVE-2017-5124 ,绕过 MHTML 对 javascript 的禁止造成的 SOP Bypass。

先来看看 Safari 的

造成 Safari 这个问题的是一个很奇怪的伪协议parent-tab:// ,看这里,在 Safari 10 中这个伪协议的主要作用是用于处理页面的后退,而重要的是,这个伪协议打开的页面拥有读取 DOM 对象的权限,比如我在 au1ge.xyz/1.htm l中有一个 script 重定向到 parent-tab://au1ge.xyz/ 那么就可以在这个 parent-tab 页面中读取到 au1ge.xyz 的 document 对象,甚至可以读到 cookie 。但是在尝试进行跨域重定向的时候,会被 SOP 拦截。而最终造成 SOP Bypass 则是使用 window.open 的 _top 参数

来看 PoC

通过 open _top 打开指向目标域的 parent-tab:// ,并设置打开页面的 innerHTML,成功执行JS

 

然后是 Chrome 的

主要原因是 Chrome 仍然支持古老的 MHTML 文档

MHTML 是 RFC 2557 定义的用来保存整个网站内容的文档格式

MHTML 可以在任意域中执行JS,只需要设置一下 Content-Location 所指向的域,而实际上在 CVE-2014-1747 中,就有利用 HTML 文件下载一个 MHTML 文件并将其嵌入 iframe 从而造成 UXSS 的案例,而在之后 Chrome 禁止了 MHTML 文件中 javacript 的执行

在更早的 MS11-26 中就有利用 MHTML 直接进行客户端脚本注入的案例

这次的 UXSS 就是对 Chrome 禁止 MHTML 中 JS 执行的一处绕过,关键点是 XSLT

通过 XSLT 来引入的 javascript 并没有被禁止执行,同时,为了让浏览器将文档解析为 MHTML ,需要将服务端的返回头设置为Content-type: multipart/related,从而达到在 MHTML 文档中执行 JS 的目的,从而达到 SOP Bypass

来看 PoC

首先是mhtml, 通过php设置header为Content-type: multipart/related来让浏览器以mhtml的格式解析文档

这个mhtml文档中有两个内容, 第一处是一个xslt, 创建了一个xsl模板并设置一个iframe指向目标域(google.com)

然后是第二处内容, 用content-location设置文档的域, 内容为js脚本, (此处的js在古老版本的chrome可以直接执行,就是第一个利用mhtml的UXSS的方法,但是目前已经被禁止执行)

然后,因为content-loacation与第一处xml中的iframe src相同,通过xsl模板将不受同源策略影响的JS引入到xml中,成功执行。

 

结论

两个 UXSS ,一个是对冷门功能/协议的利用,另一个则是对曾经存在漏洞的延伸,相同的是两个漏洞的利用过程中都体现出了所谓的“基本功”,对函数的理解,对协议、文档格式的认知。希望越来越浮躁的自己能够再次沉下心,共勉。