Firefox 在 2015 年 8 月 7 日爆了一个重大漏洞，请大家尽快更新

[Livid]

Mozilla 的官方说明：

https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/

如果你是 Firefox 的重度用户，请尽快更新。

发生安全问题的 pdf.js 组件是在 Firefox 19 里被引入的，而 Firefox 19 的发布日期是 2013 年初。所以这个漏洞已经存在了两年了？

https://wiki.mozilla.org/RapidRelease/Calendar

[Radeon]

如果 Firefox/Google Chrome/Safari 仍然坚持不进MAS，这种事情还会一再上演。或者机智的用户可以用AppArmor/SELinux自保先

[FrankFang128]

@Radeon 必然会坚持不上 MAS 呀

[caizixian]

@FrankFang128
@Radeon 求教浏览器有什么东西一定要在沙盒之外跑？

感觉硬件加速什么的可以调系统给的接口啊。

[Radeon]

@caizixian 浏览器当然应该在沙盒里跑，不在沙盒里跑一定会悲剧的

[honeycomb]

@Radeon mas是什么？

[Livid]

@honeycomb Mac App Store

[xzchina]

等TETE009版本的更新，刚去网站看了TETE还没更新

[caizixian]

@Radeon AppArmor好，个人感觉配置比SELinux上手快

[honeycomb]

@Radeon 可是Chrome/Safari自带沙盒

[Radeon]

@caizixian 显然是AppArmor好啊。SELinux一是NSA开发的，这也能信啊？二是SELinux的规则太复杂了，一个安全系统的规则如果过于复杂的话，一定会配置出错的

[caizixian]

@honeycomb 多保险总没错，Chrome／Chromium在Linux也有AppArmor／SELinux保护的

[Radeon]

@honeycomb Chrome/Safari的沙盒是自调沙盒API的做法，远没有MAS软件通过系统强制的、全程进沙盒的方式保险。实际上你打开Activity Monitor，Chrome/Safari的sandbox那一列都是"No"

[Radeon]

@caizixian 据我所知Chromium在很多发行版上默认是没有SELinux/AppArmor保护的，Firefox也没有

[caizixian]

@Radeon 至少Ubuntu是有的
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/AppArmorProfiles

[Livid]

这个漏洞目前主要是在各种广告网络上被利用，所以类似 uBlock 这样的插件，对防御类似问题可能会有一定帮助：

https://www.ublock.org/

[Radeon]

@caizixian 默认没有启用AppArmor

[Radeon]

@caizixian 看脚注2 “Will be disabled by default and be opt-in for advanced users”

[honeycomb]

@Livid 谢谢，不该这么不经大脑就问，其实稍微搜一下就明白了
@caizixian 基本看不懂Android里用的SELinux规则

[caizixian]

@Radeon 好吧，我是系统一装完就开了

@Livid 如果像report里说的那样拿.bash_history 或者搜索带有credential的文件的话，问题就很严重了。

[Livid]

为了防止将来 PDF.js 又爆什么其他的漏洞，可以从 Firefox 的 about:config 里将其彻底禁用：

about:config

pdfjs.disabled => true

[PP]

最新版本 39.0.3

https://www.mozilla.org/en-US/firefox/all/

[RAKE]

平时不浏览什么羞羞的网站就好了 XD

[breeswish]

@Radeon 然而即使用了沙盒也无法避免这个 exploit。即使有沙盒，通过这个 exploit 也可以实现读取 Firefox 所有可以读取的内容，例如你保存下来的 Cookie 在磁盘上存储的文件。沙盒只能避免它读取到用户文件。

[LPeJuN6lLsS9]

从31ESR升级到38ESR了，然后莫名地不停崩溃，真是逼死老用户……

[Radeon]

@breeswish 这个是利用FF读 ~/.ssh/ ，正好是沙盒可以阻止的

[ryrubyy]

漏洞还是稍微严重的，不过文章下面的评论很欢乐- -

[zro]

本来还想着等39.01出了才更下38.01，哪知道今天一开机就跳39.03的了，更完才知道是这回事

[avrillavigne]

@hantsuki ESR 31.8 不会升级了么 ?

[typcn]

@Radeon OpenGL 里面有相当多的函数是私有 API，如果想硬件加速，除了使用系统自带的那些库 metal 什么的 创建动画，否则是不可能的。 还有 审核规范里面，并不允许非 Safari 内核的浏览器通过审核。

要喷就喷苹果去吧

[honeycomb]

@Livid

ublock这种起到缓解的作用
因为比较严格的屏蔽策略是白名单，导致广告代码压根就没有被下载

pdf.js没有丢到沙盘里觉得不安全呢

@breeswish
不知道AppContainer是否能缓解此类攻击

[honeycomb]

@typcn

全程沙盘肯定会导致很多函数用不了
所以不管是Chrome还是IE(安全模式/AppContainer)/Edge(AppContainer)都至少有一个中等完整性进程来执行高权限代码

[imn1]

@avrillavigne
因为33/34时界面有了部分变化，一些扩展、脚本不兼容，直接从31到38会有问题

[Radeon]

@honeycomb Sleipnier这种全程沙盘的还不是好好的

[LPeJuN6lLsS9]

@avrillavigne 得自己手动换大版本的，关于ESR的介绍里有个版本图

[canautumn]

好像非webkit的浏览器不能进MAS，再者说，sandbox和MAS是俩不同的概念，进MAS必须sandboxed，但是不进MAS也可以sandboxed。

[Khlieb]

@ryrubyy @Radeon
Firefox 修补漏洞还是迅速

[metalbug]

palemoon64飘过，貌似没有更新

[Radeon]

@canautumn Opera进过MAS的

[canautumn]

@Radeon 那个时候估计还没有强制sandbox。不过话说回来，如果有一天Mac像iOS一样强制sandbox（虽然不可能），这些浏览器也会搞出来一个可以sandbox的版本来上架的，比如WebKit套个壳。

[lcj2class]

问个弱的问题，

既然pdf.js是完全用js实现的，他是怎么读取本地文件的呢？

是利用html5的API吗？是不是还有什么其他方式？

http://www.html5rocks.com/en/tutorials/file/dndfiles/

[wikinee]

@Livid 跪了，这么简称啊！

[Radeon]

@canautumn MAS里的美服的Opera是有sandbox的，不过现在好像下架了

[Radeon]

@lcj2class 肯定是利用漏洞劫持JavaScript解释器啊，JavaScript解释器有进程的所有权限，可以读几乎所有本地文件

[icylogic]

重度用户一直在用 Beta 版。。因为 Beta 才有 Win64 版本可用。。

[chengzhoukun]

@icylogic +1

[patr0nus]

@Radeon MAS 只是强制 sandbox，不强制浏览器引擎的，只要你的引擎能在 Sandbox 下正常工作就行。

[lsmgeb89]

@icylogic Win64 的版本有 flash 吗？

[icylogic]

@lsmgeb89 有啊，只是我禁用了，我除了在 Windows bilibili 客户端，平时也不看别的视频。。

[Radeon]

@patr0nus 是的。我知道

[RqPS6rhmP3Nyn3Tm]

安全问题个人感觉大部分还是靠用户自身的使用习惯。像 Google 这种大厂，想来不会干什么坏事。Firefox 就更方便了，自己看源码去。

要是哪天 OS X 也强制沙盒，我可能会把电脑给砸了……

[RqPS6rhmP3Nyn3Tm]

话说真希望 Flash, Java 这种猪队友能强制沙盒……

[lcj2class]

@Radeon
不知道你是如何得出这个结论的，mozilla官方博客上这样写道：

The vulnerability comes from the interaction of the mechanism that enforces JavaScript context separation (the “same origin policy”) and Firefox’s PDF Viewer. Mozilla products that don’t contain the PDF Viewer, such as Firefox for Android, are not vulnerable. The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.

个人觉得应该是利用了same origin policy机制，让inject的js代码（后面简写inject.js）与pdfjs的代码属于同一origin
跟js解释器没什么关系，但是我还是不大明白什么机制，inject.js是如何利用了pdf.js的local context，来搜索本地的文件的呢？据我所知，JS中并没有读取本地文件系统的API。

请指教。谢谢

BTW
HN的讨论这个话题的这个帖子，https://news.ycombinator.com/item?id=10021376

http://linustechtips.com/main/topic/426099-firefox-pdf-viewer-exploit-used-to-access-local-files-already-patched/


@patr0nus

[breeswish]

@Radeon 这个漏洞可以用来读取其他文件：沙盒可以阻止浏览器读取 ~/.ssh，然而并不能阻止恶意脚本读取浏览器在沙河下就可以读取的内容比如存储的 cookie database、history 之类… 有了沙盒影响确实是小很多了，不能任意读取，不过仍然是一个「重大漏洞」——沙盒并不能从根源上避免这个漏洞出现 :-(

[Radeon]

@lcj2class https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications
这里面有很多可以读用户文件系统的API，只要local file context被改写的话

[lcj2class]

@Radeon
这个我知道，主要是这里需要用<input type='file'>来选择文件，好奇他是怎么用js在后台调用这个的

[lcj2class]

@Radeon
大致明白了，
https://developer.mozilla.org/en-US/docs/Extensions/Using_the_DOM_File_API_in_chrome_code

[avrillavigne]

昨天已经被强制从ESR31.8.0更新到了ESR 38.2.0 右键菜单让我强迫症病发了。

[LPeJuN6lLsS9]

@hantsuki 我错了，漏洞发现这天或者前几天我在31ESR检查更新没发现更新，就想当然