1、CHIERI ISA 安全分析

议题名：Security Analysis of CHERI ISA

CHERI（Capability Hardware Enhanced RISC Instructions，功能硬件增强的RISC指令）利用新的体系结构功能扩展了常规的硬件指令集体系结构（ISA），从而实现了细粒度的内存保护和高度可扩展的软件分区。CHERI内存保护功能允许将历史上内存不安全的编程语言（例如C和C ++）进行修改，以针对许多当前被广泛利用的漏洞提供强大，兼容和有效的保护。它是在2020年11月由剑桥大学联合ARM公司发布的，基于Morello开源硬件平台设计的。

在CHERI中最重要的一个特性叫Capability，属于硬件级功能，软件无法修改，如上图所示，包含1-bit tag(用于标记区分capability中的非结构化数据)和128-bit capability（标记指针可访问的内存范围，权限以及对象类型等信息）。通过capability替换指针，以此提高内存安全性。比如下面的栈越界问题，执行的话就会直接抛异常退出。

针对这种内存越界问题看起来是有效的，但像UAF、类型混淆、堆栈未初始化等问题仍可以被利用。作者针对cheribsd（基于CHERI构建的FreeBSD原型）进行研究，发现两个漏洞可用于绕过限制实现漏洞利用：

1. 默认capatility length由堆、栈、全局内存分配器设置，但JSCell 堆分配除外，所以可以利用漏洞去获取JSCell堆内存，而JSCell头引用到StructureID，在苹果系统obej-c利用上可通过StructureID伪造对象实现利用。

2. JSC漏洞利用场景下，能够复制栈上的capability到其它ArrayBuffer，进而篡改其中的capability table（类似GOT，包含libc.system指针）指针，令其指向攻击者控制的ArrayBuffer，从而达到RCE。

在C/C++这种主流语言中，内存破坏漏洞是其面临的主要安全问题，通过硬件来提升安全性防御性能，特别是在业务无法快速修改代码修复的情况下，可以有效地提高漏洞攻击成本。像苹果之前也基于芯片提供PAC能力，通过硬件来通用地防御内存破坏漏洞或许是未来一种趋势。

2、Alcatraz：Hypervisor沙盒设计与实现

议题名：Alcatraz: A Practical Hypervisor Sandbox to Prevent Escapes from the KVM/QEMU and KVM-Based MicroVMs

介绍了Kata、Firecracker和gVisor安全容器方案，Kata 容器使用 KVM/QEMU 来隔离容器，亚马逊 Firecracker 创建的 microVM 使用基于 KVM 的轻量级管理程序进行隔离，Google gVisor 也使用带有用户级内核的轻量级管理程序实现隔离。不过作者重点还是讲虚拟机逃逸，因为他觉得逃出容器后，想扩大攻击面还是得逃出虚拟机。他收集了历年来QEMU与KVM的CVE漏洞，总结出3条虚拟机逃逸路径，从而得到3种攻击行为用于指导虚拟机逃逸防御方案的设计：

1. 从VM到Host创建进程

2. Host内核代码被篡改

3. Host User到root提权

最后设计并实现一款叫 Alcatraz 的Hypervisor 沙盒，用于阻止KVM/QEMU虚拟机逃逸，并且已开源 https://github.com/kkamagui/alcatraz 。Alcatraz由Hyper-box和定制化的Linux内核组成，Hyper-box是可加载的内核模块，防御虚拟机逃逸的核心，利用Intel VT技术实现对内存和寄存器的保护，阻止未授权行为（就是上面3种攻击行为）的系统调用，为KVM实现VMX指令模拟，就为了将KVM ring-1降为ring-0，因为ring-0 KVM无法执行VMX指令，同时利用VT特性提升性能；而定制化的Linux内核只有一个x86_64的系统调用接口以减少攻击面。

3、Pwning iOS 14

议题名：Hack Different: Pwning iOS 14 with Generation Z Bugz

2020年天府杯上，蚂蚁光年实验室pwn ios 14所利用的漏洞：

1、iTunes Store App 客户端XSS

利用itmss:// url scheme结合data url编码去利用，从而达到任意JS代码执行：

itms://<redacted>&url=data:text/html;,%3Cscript%3E%20type%3D%22application%2Fjavascript%22%3Epayload%20js%20%3C%2Fscript%3E

再利用JS API去获取敏感信息，比如设备指纹、本地文件、Apple ID，甚至枚举APP和执行App，弹个计算器等。

2、利用Objective-C类型混淆漏洞泄露地址绕过ASLR

iTunes.windows可通过iTunes.scriptWindowContext和iTunes.setScriptWindowContext_进行set和get操作其成员变量，可先分配任意object对象给它再读取，当iTunes.window在处理obj-C对象时，若对象无法识别selector，则会抛异常泄露对象地址，借助JS就可以读取出来：

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[SUScriptWindowContext tag]: unrecognized selector sent to instance0x10b15a470'

通过读取false对象，即可得到__kCFBooleanFalse对象地址，它位于CoreFoundation库中，借助它就可以泄露dyld_shared_cache基址，从而绕过ASLR。

3、UAF漏洞

js可以动态调用dealloc去释放内存，所以先分配对象给变量保存，再调用deallo释放，变量就成了对悬挂指针的引用，一个UAF漏洞就出来了。看作者介绍的，第2个漏洞跟这个UAF被苹果算作同一个漏洞。

最后介绍如果利用上述漏洞绕过iOS 14下的PAC和APRR实现任意代码执行。先借助iTunes.makeXMLHTTPStoreRequest去分配SUScriptXMLHTTPStoreRequest对象，再利用SUScriptFAcebookRequest类的addMultiPartData:withName:type:方法去（js上对应iTunes.createFacebookRequest(xx).addMultiPartData）设置可控长度和内容的NSURL数据，用于填充被释放的内存空间，实现fakeobj构造。

iOS 14开始已经对isa指针引入PAC保护，但从iOS 14.5开始才检查，之前都没做检查，所以可以利用这个空窗期采用Project Zero在iMessage中所用的方法：SeLector-Oriented Programming绕过PAC，即通过伪造包含一连串NSInvocation对象的NSArrary，通过@selector(invoke)参数调用makeObjectsPerformSelector:实现任意的Objective-C方法的调用。接下来通过前面绕过ASLR的漏洞实现内存任意读，用来绕过苹果对NSInvocation随机数检查（用于针对内存伪造对象的检查）。最后结合堆喷实现利用，作者也给出不用堆喷的方法，有兴趣的同学自己去看吧，这越写越多了。

iOS通过APRR启用每个线程的页面权限，通过专用CPU寄存器将页表条目权限映射到它们的真实权限来实现的，使得任何页面都无法同时具有可写和可执行权限。作者是利用Webkit在JIT编译生成机器码时会用到内联函数performJITMemcpy，它可以将任意代码复制到JIT区域，通过它就可以绕过APRR写入任意机器码：

// set writable

pthread_jit_write_protect_np(0) ;

// write shellcode

memcpy( jit_function , code , size );

// set executable

pthread_jit_write_protect_np(1) ;

原作者在公众号上也写过详细的利用介绍，比blackhat ppt写得更加详细：

Mistune 漏洞利用：滥用 Objective-C Runtime 过 PAC

4、Chrome漏洞挖掘与利用

议题名：Put in One Bug and Pop Out More: An Effective Way of Bug Hunting in Chrome

像Chrome这种难度比较大的目标，如果不能找到一个新的攻击面，靠Fuzz可能收获比较小，且有可能撞洞，有不少人都通过代码审计去挖。尤其是CodeQL的出现，更加简化这种工作，非常适合定制化规则去辅助漏洞挖掘，哪怕是一些逻辑漏洞，也可以支持，撞洞也会少一些。最近2年来，特别是一些难度大一些的主流产品，似乎不少安全研究人员开始尝试分析历史漏洞，梳理出漏洞模式，借助CodeQL制定规则去扫描，本议题也是如此思路。通过分析3种类型的历史漏洞：RenderFrameHost issue、Error return issue、WeakPtr Optimization issue，总结出漏洞模式，借助CodeQL制作规则去扫描，有一次从363条扫描结果中挖3个漏洞，其中一个被用在天府杯上。最终，在Chrome上挖到24个漏洞，已获得11个CVE，说实话，这效果也太好了。但像Chrome这种目标，即使扫出来，如果不花时间去阅读理解源码，也比较难发现，这就考验你去代码的理解程度了。但不得不说，分析历史漏洞总结出漏洞模型，借助CodeQL制定规则去挖掘漏洞，确实是当前的一种方向，因为同一个人写出个漏洞，那么他就有可能在其他地方搞出类似漏洞出来，这就有了大家常说的变形分析（Variant Analysis），即根据历史漏洞挖掘其它相似漏洞。

5、飓风山竹：远程通杀Root利用链

议题名：Typhoon Mangkhut: One-click Remote Universal Root Formed with Two Vulnerabilities

来自360 alpha lab的议题，介绍如何利用CVE-2020-6537 V8漏洞实现RCE，再结合CVE-2020-0423 Android Binder漏洞进行root提权，进而实现Chrome 沙盒逃逸。

第一个v8漏洞CVE-2020-6537是Promise.allSettled()上的一处类型混淆漏洞，它会返回一个所有给定promise已经fulfilled或rejected后的promise，并带有一个对象数组，每个对象表示对应的promise结果。每解决完一个输入的promise，remainingElementsCount就会减1，当它为0时，就会返回一个JSArray数组。

但如果能够同时调用resolveElementFun和rejectElementFun，就会令remainingElementsCount-2，可以更快返回JSArray，然后通过赋值整数将JSArray更改为NumberDictionary，造成类型混淆，再将其转换成越界读写进行漏洞利用。不过ppt里面没有给出完整poc，尝试上chrome issue去找找poc/exp，发现没权限(https://bugs.chromium.org/p/chromium/issues/detail?id=1105318)，2020年的漏洞到现在都还没公开，只能就此作罢。

第二个漏洞CVE-2020-0423 Android Binder UAF漏洞，网上也有人分析过：https://www.longterm.io/cve-2020-0423.html，并附有poc。漏洞本质上是多线程操作进行条件竞争导致的UAF：

1、先发送BINDER_TYPE_BINDER命令的transaction给binder，binder会创建包含binder_work的binder_node附加到thread->todo表中，并发送给receiver接收者；

2、然后发送BINDER_THREAD_EXIT命令消息去中断通讯，然后调用binder_relsease_work将binder_node从thread->todo表中删除，释放节点；

3、receiver为响应第一步的transaction，发送BC_FREE_BUFFER（ppt里面写错了）命令去释放binder_node，但它已经被释放了，最终导致UAF。

利用上，先利用漏洞binder_release_work转换成double free，然后采用sendmsg和signalfd来做稳定的堆喷；再通过binder_thread_read读取seq_file结构（linux文件系统操作接口）的op指针，从而获得泄露的内核地址绕过kaslr；再劫持freelist指针，然后利用KSMA攻击方法实现root权限（https://i.blackhat.com/briefings/asia/2018/asia-18-WANG-KSMA-Breaking-Android-kernel-isolation-and-Rooting-with-ARM-MMU-features.pdf），即向内核页表中写入一项描述符，供用户态可以随意读写内核。