引言
有很多应用广泛的技术却往往看起来是一个奇怪的主意。IT届的不少工程决策是在信息不完善与时间压力下进行的,因此系统中的很多古怪问题就显得“当时看来是个好主意”。本篇文章中探讨的WPAD(“Web代理自动发现协议”,更具体地说是“代理自动配置”)正是其中之一。 互联网之初——在1996年的时候,Netscape的工程师认为JavaScript是编写配置文件的最好的语言,因此PAC成为配置文件的格式,其工作原理如下:浏览器连接到预先设定的服务器,下载PAC文件,并执行特定的JavaScript以确定正确的代理配置。不过它也有其优势,比方说它就比XML更具表现型且不那么冗杂,而且可以向许多客户端提供配置信息。 PAC本身加上了一个名为WPAD的协议,它使得浏览器不需要预先设定服务器来连接。WPAD可让计算机查询本地网络以确定加载PAC文件的服务器。 不知何故,这项技术最终写进1999年的IETF草案。直到现在,每台Windows计算机都会询问本地网络:“嘿,我在哪里可以找到一个Javascript文件来执行?”。这可以通过多种机制来实现:DNS,WINS,也可以是DHCP。 近年来,浏览器的利用已经从主要面向DOM发展到直接面向JavaScript引擎,所以假如我们可以在不借助浏览器的情况下通过网络来执行Javascript那就是个很好的方向。最初的调查显示,负责执行这些配置文件的JS引擎是jscript.dll——同时也支持IE7和IE8的传统JS引擎(如果使用适当的脚本属性,在IE11中仍然可以在IE7 / 8兼容模式下访问)。这是把双刃剑——一方面,这意味着不是每一个Chakra的错误都会导致远程攻击,但另一方面,这意味着一些相当老的代码将负责执行我们的Javascript。 安全研究人员先前已警告WPAD的危险性。但是,就我们所知,这是第一次发现对WPAD的攻击。 Windows并不是唯一使用WPAD的,其他操作系统和应用程序也在用。例如Google Chrome也有一个WPAD实现,但在Chrome的情况下,是在一个沙箱内执行PAC文件的JavaScript。而其他支持WPAD的操作系统默认是不启用它的。这就是为什么Windows是目前这种攻击最倾向的目标。
WPAD(Web Proxy Auto-Discovery)
详情见原文
漏洞情况
我们花了一些时间手动分析与模糊测试jscript.dll中的漏洞。最开始遇到了一些困难,因为很多用于触发JavaScript引擎中的错误的“特性”不能在JScript中使用,仅仅是因为它太老了没法支持这些特性。例如:- 缺乏数组类型(int数组,float数组等),因此混淆数组类型是不可能的。
- 没有现代JavaScript引擎优化(“快速路径”),这些快速路径往往会导致漏洞。
- 不能在通用JavaScript对象上定义getter/setter。可以调用defineProperty但DOM对象于我们没有帮助,因为在WPAD过程中不会出现DOM。即使它存在,当调用一个带有“预期的JScript对象”消息的DOM对象时,很多JScript函数也会报错。
- 对象创建后改变对象原型是不可能的(即没有“__proto__”属性)。
漏洞类型 | 影响IE8模式的漏洞 | 影响IE7模式的漏洞 |
释放后利用 | 1340,1376,1381 | 1376 |
堆溢出 | 1369,1383 | 1369,1383 |
未初始化变量 | 1378 | 1378 |
溢出 | 1382 | 1382 |
总计 | 7 | 5 |
利用
详情见原文
结论与防护
执行不可信的JavaScript是非常危险的,在非沙盒JavaScript引擎中(如jscript.dll)更是如此。我们找出了7个安全漏洞,并在安装了Fall Creator Update的Windows 10 64位计算机上成功进行利用,可触发本地网络(或其他地方)任意代码执行。 现在漏洞已经修复了,这是否意味着我们可以收工回家睡觉?可惜并不是。尽管我们花费了相当多的时间和精力来找寻jscript.dll漏洞,但是我们并不认为我们发现了所有的漏洞。事实上,可能不只有7个,也可能会有8个甚至更多。 那么,微软可以做些什么来提高这类漏洞的利用难度呢:- 默认禁用WPAD。实际上,目前Windows是唯一一个默认启用WPAD的。
- 为WPAD服务内的JScript增加沙盒环境。
- 在控制面板中关闭“自动检测设置”
- 设置“WpadOverride”注册表项
- 将“255.255.255.255 wpad”放在hosts文件中

版权声明
本站原创文章转载请注明文章出处及链接,谢谢合作!
评论