本文为《SSD Advisory —— Chrome AppCache Subsystem SBX by utilizing a Use After Free》的翻译文章。第一次翻译二进制文章,如有错误,请指正,私聊或者留言即可,谢谢~。

漏洞概要

这个漏洞存在于Chrome 69.0及其以下版本的AppCache子系统中,所涉及的代码恰好位于沙箱之外的某些可获得特定权限的浏览器进程中。渲染器通过向浏览器进程发送IPC消息来与SBX子系统进行交互,这些IPC信息又可能让浏览器发出网络请求。攻击者借此通过控制请求进而完成UAF漏洞利用,达到想要的效果。

官方响应

Google官方已经在Chrome 70版本修复了此漏洞。

CVE

CVE-2018-17462

漏洞提交者

两位独立安全研究人员Ned Williamson和Niklas Baumstark向Beyond Security公司的SSD团队报告了此漏洞。

受影响的系统版本

Google Chrome 69.0 及其以下版本

漏洞详情

这个漏洞在Chrome浏览器的Appcache子系统中 。能够从渲染器进程到代理进程中的IPC消息又可以 调用出问题发生漏洞部分的代码段,再加上,AppCache是一个采用引用计数方式的对象组件,所以当用户清空应用缓存的时候,就能触发RemoveCache函数,从而通过这种方式将被释放对象的引用数值在原来j基础上上加上新的增量N*。

译者注:增量N(也可能是减量N,N不一定用于增加,后续会涉及) 的产生是因为清楚了应用缓存,N值具体为多少取决于消除的什么类型应用缓存

不过值得注意的是,我们可以从上图可以了解到,清空缓存的时候,newest_complete_cache_才是会被释放销毁的对象。如果我们先把newest_complete_cache_设为NULL,然后调用CancelUpdate进行修复,再通过将newest_complete_cache_对象的引用计数递减为0来实现进一步的漏洞利用。一旦newst_complete_cache_被引用并且当引用完对象,销毁引用项后,引用计数就会变为0,同时释放对象,从而为后续利用UAF漏洞创建更强有力的条件。(这样看来应该可以总结成类型混淆吧?*)

译者注:这种手法确实是类型混淆的概念。什么是类型混淆呢?它分为很多种种类,但是核心思路大同小异,形象来说就好比你想买超能牌的洗衣液(所需要的类型),去超市拿洗衣液的时候却拿到了趄能牌洗衣液(通过混淆伪装的类型),可是你没查看清楚,以为是超能洗衣液,于是拿着就结账走人(成功执行),在我看来简单来说就是,把不是你所需要的东西通过伪装成功传递给你并且执行成功。不过我也是刚接触这个概念,如有理解错误的话,请指正,谢谢。

漏洞利用

正是这个缺陷给我们提供了两条重要的基础条件:

  1. 释放后调用被释放对象的第一个双字节中由N决定的递减量,同时N也是由这个对象所决定的。
  2. 如果在递减过程中,第一个双字节部分变为0,就会调用AppCache析构函数并且释放指针。

我们分两个阶段使用这两个条件:

  1. 构造信息泄露点
  2. 触发执行代码进行漏洞利用

释放的AppCache对象的大小为0xA0字节。我们发现net::CanonicalCookie具有相同的大小,因此我们可以通过发出网络请求,同时在响应包中包含cookie的方法来达到浏览器运行进程中散播cookie的目的。

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖