Java语言是最为流行的面向对象编程语言之一， Java运行时环境（JRE）拥有着非常大的用户群，其安全问题十分重要。近年来，由JRE漏洞引发的JVM逃逸攻击事件不断增多，对个人计算机安全造成了极大的威胁。研究JRE安全机制、JRE漏洞及其挖掘、JVM逃逸攻防技术逐渐成为软件安全领域的热门研究方向。
针对Java层API与原生层API, JRE安全机制分别包括JRE沙箱与JVM 类型安全机制。本文针对JRE沙箱组件及其工作原理进行剖析，总结其脆弱点；分析调研JVM安全机制，提出其脆弱点在于Java原生层漏洞，为JRE漏洞挖掘工作提供理论基础。
对于JRE漏洞，本文进行漏洞分类研究，提取Java API设计缺陷、Java原生层漏洞两种JRE漏洞类型的典型漏洞进行分析，总结漏洞特征，为漏洞挖掘工作建立漏洞模型。
根据JRE漏洞分析中建立的漏洞模型，本文采用源代码审计的方法开展Java API设计缺陷类型的漏洞挖掘工作，发现了数个Oracle JRE、OpenJDK和Apple JRE 的 Java API 设计缺陷问题。在 Java原生层漏洞挖掘工作中，出于Java原生层漏洞的特殊性，本文基于程序分析领域的符号执行技术提出一种寄存器符号化监控方法，选取开源符号执行平台S2E作为漏洞挖掘工具，并且基于其实现了针对JRE原生层漏洞挖掘的辅助插件 SymJava 和 SymRegMonitor，基于 OpenJDK 和 Oracle JRE逆向代码进行源代码白盒审计并构建了用于进行漏洞挖掘的 Java 测试用例，最后对36个调用Java原生层API的Java测试用例进行实际测试发现了共计6 个 JRE原生层安全隐患，其中2 个可被攻击者恶意利用，并给出漏洞分析和 PoC。
针对 JVM 逃逸攻防问题，本文分别从攻击和防御角度，提出 JVM逃逸攻击的5 个关键元素，针对每个元素进行攻防技术研究，并通过绕过杀毒软件静态检测的实验证明了本文提出的 JVM 逃逸攻击技术。最后，本文从多角度给出JVM逃逸攻击的防御策略。
目录
3 JRE漏洞分析
3.1 JRE 漏洞分类研究
3.1.1 Java API 设计缺陷
3.1.2 Java 原生层漏洞
3.1.3 类型混淆
3.1.4 自签名问题
3.2 典型 JRE 漏洞分析
3.2.2 CVE-2012-5076
3 JRE漏洞分析
近年来，因 JRE 漏洞发起的 JVM 逃逸攻击事件逐渐增多。在安全界，针对JRE 漏洞的漏洞挖掘研究也逐渐成为热门。国内的一些安全论坛上涌现了许多关于JRE漏洞分析的文章，颇具代表性的如一文。2013年的安全技术会议如Blackhat、 XCon、 HITCon、 SyScan360等等都收录了关于JRE漏洞分析、利用、挖掘方面的议题。美国的知名漏洞收录库 ZDI中，2012-2013 年安全研究员提交的JRE漏洞所占比例也较往年呈现显著的上升趋势，如图3-1所示。
鉴于 JRE 漏洞研究的热门程度，本章对现有 JRE 漏洞进行分类研究和原理性分析，作为JRE漏洞挖掘研究和JVM逃逸技术研究的前瞻性工作。
3.1 JRE 漏洞分类研究
由表3-1 可知， JRE 漏洞主要可以划分为三大类：
1.权限/沙箱问题。基本是由Java API设计上的缺陷导致，包括不安全的反射机制使用、类型混淆等等。
2.缓冲区操作异常。由原生层方法缺陷导致，包括堆溢出、栈溢出、越界
访问（越界读和越界写）等等。
3. 其他安全问题。包括进程受控、操作系统命令注入、Use-After-Free等等。
其中，权限/沙箱问题在数量上占据了主导地位。基于上述JRE漏洞分类，本小节将其总结为Java API设计缺陷和Java原生层漏洞，分别作详细阐述。又因为类型混淆原理上的特殊性，本小节单独从Java API设计缺陷中将其单列出来进行阐述。最后，本小节特别介绍一种容易被广大安全研究人员忽视的安全问题：Java Applet 的自签名问题。
3.1.1 Java API 设计缺陷
Java API设计缺陷是指，存在这样的 Java API，使得：
1. 该 API 本身可以被任意调用或者通过一条“信任链”被间接调用；
2. 该API的参数可以被调用者完全或者部分地控制
3. 该API被调用后可以完成获得任意类对象、获得任意方法对象、获得任意域对象、以Bootstrap Classloader来加载任意指定类等恶意行为。
满足上述3 点的 API 叫做缺陷 API, Sun 和 Oracle 的 JRE 开发者定义这些API的初衷是用于开发所需，由于安全意识上的疏忽而没有考虑到会被攻击者用于绕过JRE沙箱。API缺陷型漏洞往往有一个“信任链”问题，例如缺陷API存在于 C 类中，而 C 类是不可以被调用的，但通过源码审计得知 B 类调用了 C类的缺陷API，而A类又调用了B类。
3.1.2 Java 原生层漏洞
Java 语言是一种类型安全的语言。所谓“类型安全”，是指 JVM 提供的一系列类型安全机制，如2.2小节提到的结构化的内存访问、自动化垃圾收集、数组越界检查、空引用检查、严格的类型转换检查等等。对于Java开发者而言，这些安全机制是对他们透明的。Java程序员认为的JVM的安全性只是建立在信任原生层 API 的基础之上的安全，而假如原生层实现中没有检查数组边界或者有不安全的指针类型转换，则会导致一系列安全问题。Java原生层中出现的漏洞也占据一定比例，如 CVE-2009-3867，在 MidiSystem 类中的 getSoundbank 方法是一个原生层方法，参数是一个不限长度的字符串，而在底层 C 代码实现中，没有经过长度检查而直接调用了一个strepy，造成了栈溢出1.2013年以来，Java7被曝光了几个可以利用Java大数组修改安全管理器对象的漏洞，究其根本是数组越界访问问题，比较著名的有 CVE-2013-1493，其漏洞原理将在3.2.3 小节中深入讨论。
3.1.3 类型混淆
由于Java语言有着严格的类型转换检查机制，从这一点出发可能会得出类型混淆（Type Confusion）这种漏洞在Java中难以存在和利用的结论。查阅hotspot虚拟机的源代码，可以看到如表3-2所示的类型定义。
虽然 hotspot对于Java变量的类型检查是非常严格的，但如果在反射API中出现逻辑漏洞，还是可以从Java API层来实现类型混淆的。较为典型的此类JRE漏洞有CVE-2012-050718】，黑客利用该漏洞，使用恶意软件Flashback曾感染了多达10万台的Mac个人计算机119.由于类型混淆类漏洞的特殊性和热门度，本章将其单列出来进行阐述，并在3.2.4 小节中分析一个典型的类型混淆漏洞CVE-2013-2423.
3.1.4 自签名问题
在Oracle JRE 7 update 10版本之后， Oracle采取了新的"click-and-play"安全策略：在运行Applet之前，向用户弹出一个安全警告对话框，提示用户运行该程序有风险，如图3-2 所示。在 Java 控制面板的“安全”标签中，默认安全等级也不断提高，从原来的默认“中”提升到现在的“高”。
首先，编写一个简单的 Applet，代码如表3-3 所示。这个Applet 仅调用了一个API，通过cmd命令实现打开Windows计算器的功能。在未签名情况下，这样的调用方式会抛出访问拒绝的异常。假如对这个Applet进行自签名，执行结果却有所不同。自签名的方法可以在互联网上找到相关资料，用到的工具有三个，如果在Windows系统中安装了Oralce JDK，可以在目录<JDK-HOME>/bin下找到这三个工具：用于生成jar包的jar.exe、用于给jar包签名的jarsigner.exe以及用于生成秘钥的keytool.exe。
签名的步骤如下所示：
1. 第一步，把编译好的 class 文件打进 jar 包，cmd 命令如下：jar cvf TestApplet.jar TestApplet.class
2. 第二步，使用 keytool 生成自己的私钥并存储到文件里：keytool-genkey-keystore test.store-alias test
3.第三步，导出.cer 证书：keytool-export-keystore test.store-alias test-file test.cer
4.第四步，给 jar 包签名：jarsigner-keystore test.store TestApplet.jar test
在签名过程中，签名工具会要求输入一些信息，如开发者姓名、公司等等，这些信息都是可以任意填写的。
最后，用html页加载执行这个Applet，用浏览器打开该页面，发现会弹出安全警告，如图3-3 所示。
点击“详细信息-证书详细信息”，可以看到之前填写的一些签名信息，如图3-4 所示。
3.2 典型 JRE 漏洞分析
本节对四个典型JRE漏洞进行研究与分析，包括三个Java API设计缺陷：CVE-2012-4681、 CVE-2012-5076、 CVE-2013-2423， 其中 CVE-2013-2423 是一个类型混淆漏洞。此外还有一个 Java 原生层漏洞：CVE-2013-1493。
3.2.1 CVE-2012-4681
CVE-2012-4681 是一个经典的不安全反射 API设计的例子。该漏洞的问题根源在于sun.awt.SunToolkit类的getField方法，通过查看OpenJDK源码，可以看到其具体代码，如表3-4所示。
这个方法的作用是获取指定class对象的指定名称的域，可以看到，这段代码其实是包裹在一个doPrivileged权限提升代码块中的，也就是说不用经过调用栈检查。而且该方法具体实现是靠反射API class.getDeclaredField，由表2-7可知它可以用来获取所有声明过的域，无论公有还是私有。
这样可以构造出一个工具方法，通过SunToolkit.getField缺陷API 来实现设置任意类的任意域的功能，如表3-5 所示。
实现JVM逃逸的最终目标是将安全管理器设置为null，进一步说，要利用的缺陷API应该可以用于置空SecurityManager的上下文中。第二章已经介绍过用Expression调用静态方法这一手段，通过阅读 Expression类的源码可知，其大多数函数继承java.beans.Statement类，例如Expression的执行方法execute（）就调用了父类的invoke0方法。查看Statement类中invoke的源代码，如表3-6所示。
invokeInternal（）是 execute（）方法的实际执行点，它同样被包裹在 doPrivileged代码块中，另外还指定了一个所谓“保护域”参数acc，它是AccessControlContext类的一个对象，在 Statement 中可以找到其定义，如表3-7 所示。
首先构造一个Statement 表达式，用于执行 setSecurityManager：然后构造一个拥有最高权限（AllPermission）而且保护域为本地执行（file:///）的一个类型为 AccessControlContext 的对象，这些都可以通过查 Java API 文档了解到：最后，使用之前写好的SetField方法，将这个statement的acc域替换为自定义好的高权限accesscontrolcontext 对象，最后执行这个 statement。编译执行 Poc 代码可以发现安全管理器成功被设置为 null.
漏洞 CVE-2012-4681 的利用思路如图3-5 所示。
3.2.2 CVE-2012-5076
CVE-2012-5076 【22】原理较CVE-2012-4681有些复杂，需要调用到三个缺陷API.存在缺陷API的类分别是：
1. com.sun.org.glassfish.gmbal.ManagedObjectManagerFactory；
2. com.sun.org.glassfish.gmbal.util.GenericConstructor；
3. sun.invoke.anon.AnonymousClassLoader
首先分析 sun.invoke.anon.AnonymousClassLoader 这个类，通过源代码分析发现 loadClass 方法，其源代码如表3-9 所示。
该方法支持以字节数组的形式加载一个class，其核心实现是一个私有方法fakeLoadClass，通过阅读其源码可以发现，它最终会调用sun.misc.Unsafe类的defineClass方法，而这个方法会以Bootstrap Classloader来加载任意class的方法。当然，也包括开发者自定义的 class。作为攻击者，可以定义这样一个恶意的提权类，如表3-10 所示。
提权类MyPayload继承了PrivilegedExceptionAction，并通过绕过栈检查的AccessController.doPrivileged方法来实现关闭securityManager的行为。通过查看相关 API，攻击者可以轻易地构造出这样一个类。假如这个自定义的提权类由Bootstrap Classloader来加载执行，那么JRE沙箱的安全管理系统将被彻底关闭。
