昨天微软发布了一篇关于“新旧隔离机制”的文章[译者注:隔离任意 native 代码的执行]，我个人非常赞同他们给 Edge 整上这个机制，但外面有些个反应简直夸张的不真实。来看看 Dan Guido 的 Twitter (对不住了 Dan ~😉):

毫无争议, Edge 一跃超过 Chrome 成为了最安全的浏览器！ https://t.co/JeE08LHBBv ——@dguido

在这件事上，我认为对比 Chrome 来反观微软这次的动作，弄清楚浏览器的世界里发生了什么更为重要。当然，作为 Chrome 安全的工程指导我可能会偏心。但是，我的工作要求我客观的评价各种安全机制从而指导我的团队的努力方向，所以理论上我要作出的结论还是挺“清白”的。

EvsC

缓解远程代码执行(RCE)

对于前端的远程代码执行，微软可是下了大功夫。它试图通过防止攻击者获得可靠的代码而打破漏洞利用的第一环，如果成功的话就可以完全阻止攻击者。但最后仍然会演变成猫捉老鼠的游戏，缓解虽然可以消耗攻击者更多精力，却不能从根本上阻止漏洞利用。

个人来说，我认为微软此次的着眼点仅仅是放在了 IE 和 Edge 最常受到的攻击类型上，“让数据说话”也的确不失为一种合逻辑的策略。这样的话就有一大堆新的 RCE 缓解技术，连同着其与 chrome 类似技术的对比，我在下面列了写值得注意的几项:

  • 内存回收
    通过回收 DOM 对象、在 free 操作时作缓解，内存回收降低了可利用的 use-after-free 漏洞出现的可能性。这能与 Chrome 的 use of Oilpan 类似，通过回收 DOM 对象、分块分配内存，采用不同的缓解措施，来对抗发生中的 use-after-free 利用。总的来说，内存回收只是 Chrome 在这块儿的一个小特点，相对来说 Chrome 没有那么多可利用的漏洞，这局打平。

  • 执行流保护(CFG)

CFG 提供完整的执行流表，在“预防直接执行非法路径”上作了增强，Edge 在内部代码和系统库都用了 CFG。而Chrome 只在系统 DLL 用了 CFG， 另一方面不是 Chrome 内部而是用在了 Clang/LLVM 工具链上，使得我们可以使用 Clang 的 CFI 检查，非常好地契合了 Chrome 的需求。CFI/CFG 是未经过实际检验的技术，未来还可能出现重大的弱点和设计缺陷，总的来说是 Edge 占了上风。

  • JavaScript JIT 加强

微软在“防止漏洞利用时利用 JIT ”方面做了很多工作，其中最创新的莫过于将 JIT 移出进程，不让沙盒中的进程直接创建可执行页面。攻击者必须完整编译 RCE 成 ROP 链，这可要费大工夫了。无可否认，虽然 v8 要推出 JavaScript 解释器（ignition）和 JIT 的替代品（turbofan），Chrome 的性能会大幅提升，但是 Chrome 当前的 JIT 缓解措施还是比微软弱。这方面 Edge 遥遥领先了 Chrome。

安全隔离机制

微软在 RCE 缓解方面比 Chrome 投入更多，Chrome 更专注于在浏览网页时定义和加强持续可用的隔离边界。像微软一样，Chrome 也是受暴露的漏洞类型驱动的。然而，两家是有不同的理念和实施约束的，通过长期观察，我们发现隔离机制反而是更有效的策略，跨平台也更方便。

首先，从安全机制的长期有效性来看，我们在 Chrome 上发现，随着时间的推移，底层 OS 平台倾向于提升安全隔离原语。比如说 Linux 的衍生系统会使用 seccomp-bpf 机制，修改系统调用表，Windows 系统会使用integrity level(IL)， 锁定 win32k 上的进程缓解策略。在安全隔离方面，我们现在有能力利用这些操作系统作出的安全上的改进。

说到可移植性，拿微软最近的 JIT 加强来说，它依赖于 Windows 10 上 Edge 的新特性，并且受限于微软的签名文件。现在这种 OS 限制已经不常见，工程师们也可以找到替代方法解决，但是考虑到这项功能涉及修改主架构，必须确定这对其他平台是否友好，或者解释说是安全上作了重大改进，然而这两种说法都不现实。

比起 Edge， Chrome 的渲染器处在更强有力的沙箱保护中。

Chrome 在创建更强的隔离原语（如 Chrome 的渲染器比 Edge 处在更强的沙箱保护中）和扩展其应用方面（如 GPU 沙盒、网络沙盒）做出了更大努力。

这方面我们的王牌是今年推出的站点隔离项目，站点隔离是数十年的工程成果，为 web 源加上限制，从而阻止渲染器沙盒 RCE 操作其他 web 源。这比现今其他任何浏览器的安全保证都更强壮有力。

这篇文章的点在哪？

浏览器安全是个复杂的话题。所以我想为 Chrome 现在的决策作一些说明，以及为什么我认为这些决策仍然可以捍卫 Chrome 在各个平台作为最安全浏览器的地位（事实证明）。

现在问题是有一些现象把安全研究降低成简单地划划清单，或者是互相比较安全特征/CVE 的游戏，这些东西对评估真实的安全没一点用处。浏览器的架构是软件里最复杂的，背后的决策对我们也是不透明的。我确实认为我们做了正确的决定，优先解决着 Chrome 最要紧的问题。我承认如果我负责的是 Edge 的安全，我会针对不同的用户拿出不同的数据，最后做出个不一样的结论。

以我们的共同点结束如何？

微软的博客里关于 Edge 如何防止第三方代码注入这点非常有意思，这也是所有浏览器大头的点。第三方应用使用不当操作插入代码不仅会造成稳定性问题和性能问题，也妨害着浏览器安全。我一直说我们为什么一直不能在 Chrome 沙盒里启用 Lowbox Token（App 容器安全限制）和 CSRSS 限制，因为那时第三方的反病毒程序会造成 Chrome 崩溃。

很高兴看到微软利落的切入了 Edge，为阻止第三方注入开了先河。Chrome 和 Firefox 今年也准备部署类似的方案，在这一点上为了最好的帮助用户我们达成了结盟。

原文链接: Securing Browsers Through Isolation Versus Mitigation

本文首发于看雪。