转载

Java反射库中的安全漏洞在30个月后终于修复了

　　英文原文：Vulnerability in Java Reflection Library Fixed after 30 Months

　　2013 年 7 月，安全组织 Security Explorations 发现了 Java 7u25 中的一个安全漏洞，通过这个漏洞攻击者可以完全摆脱 Java 沙箱。Oracle 在更新的 7u40 中包含了一个补丁，但是据 Security Explorations 在今年早些时候声称，这个补丁仅仅在理念上对其进行了修正，对代码稍加修改之后，依然可以利用这个漏洞。另外，随后的研究表明这个漏洞甚至比最初报道的更加严重。在这个问题公开之后，Oracle 发布了一个补丁，作为8u77的一部分。

　　这个漏洞可以在新的反射库中找到，该库从 Java 7 以后均可以使用，更具体来讲，是在使用新的 MethodHandle 类动态访问和调用方法的时候。它与不同 ClassLoader 加载类的方式有关。要理解这个问题，需要一些基本的知识，这些知识涉及到 Java ClassLoader 的工作方式，因为类加载是在 Java 中大家了解最少的领域之一，所以在阐述这个问题本身之前，我们会首先概述一下这个理念。

　　Java ClassLoader

　　Java 能够在运行时从各种来源动态加载代码。这种功能是通过一系列名为 ClassLoader 的特殊类来实现的。标准的 Java 实现会提供多个 ClassLoader 来加载类，它们能够从文件系统、URL 或压缩文件等位置加载类，不过 Java 也为开发人员提供了创建自定义 ClassLoader 的能力，以应对个性化的需求。与 ClassLoader 交互的常见方式是调用其 loadClass (String)方法，这个方法会接受类的名称，如果能够找到的话，就会返回相关的 Class 对象，如果找不到的话，就会抛出 ClassNotFoundException 异常。在 Java 应用中的每个类都是通过某个 ClassLoader 按照这种方式加载的。

　　通过设置父 ClassLoader，这些不同的 ClassLoader 能够互相连接起来，形成一个层级的结构。如果没有设置父 ClassLoader 的话，那么父 ClassLoader 默认将会设置为加载该 ClassLoader 的那个类加载器（ClassLoader 本身也是类，因此也需要通过某个 ClassLoader 来进行加载）。如果提供了父 ClassLoader 的话，那么 ClassLoader 的默认行为就是将加载所请求类的任务委托给它的父加载器，只有父加载器（或祖父加载器）无法加载这个类的时候，这个 ClassLoader 本身才会试图加载所请求的类。但是，自定义加载器的创建者并非强制性要求遵循这种默认行为，他们完全可以选择实现不同的行为。

　　当 Java 应用启动的时候，如下的 ClassLoader 将会按照顺序发挥作用：

Bootstrap ClassLoader：JVM 本身的一部分，因此在每个 JVM 中，它的实现都是特有的。这个 ClassLoader 没有父 ClassLoader，它用于加载 java.lang 包下的核心类。
Extension ClassLoader：负责加载扩展库中的类，在每个 Java 安装环境下可能会有所差别。Extension ClassLoader 将会加载 java.ext.dirs 变量所指定路径下的所有内容。
Application ClassLoader：负责加载应用程序的主类以及所有位于应用类路径下的类。
Custom ClassLoader：应用程序中使用的所有其他的 ClassLoader。它是可选的，根据应用的情况不同，它可能并不存在。

　　在运行时，使用自定义的 ClassLoader 动态加载类为很多的应用创造了可能性，否则的话，有些功能可能是无法实现的，不过，遗憾的是，它也造成了很多的安全问题，尤其是在类仿造（class impersonation）方面。理论上，开发人员可以创建一个自定义的 ClassLoader，让它来加载原始类 java.lang.Object 的一个模拟实现，并在应用程序中使用这个自定义的对象。这可能会在两个方面引发安全问题：这个自定义的对象能够访问 java.lang 包下所有包范围内可见的类内容；其次，这个自定义的 Object 会被 JVM 作为标准的 Object 对象，因此会将其作为由 Java 实现的可信任的类。

　　为了保护 Java 以应对这些安全问题，Java 类要通过三个属性来进行识别：类名、包以及 ClassLoader 的引用。如果两个不同的类具有相同的类名和包名，但是由不同的 ClassLoader 所加载的话，Java 会认为它们是不相等的，在它们两者之间进行赋值的话，将会导致 ClassCastException 异常。这样的话，就能保护环境免受类仿造的攻击。

　　部分修复以及由此导致的漏洞

　　Security Explorations 最早报告了这个漏洞，并将其归类为 CVE-2013-5838，这个漏洞可以描述为，当通过 Method Handle 调用方法时，对于被调用方法的那个类，它的 ClassLoader 并没有进行检查，这意味着攻击者可以按照上文所述的方法进行类的仿造。

Java反射库中的安全漏洞在30个月后终于修复了

　　展现原始漏洞的代码样例，目标类的 ClassLoader 并没有进行检查；来源：Security Explorations。

　　Oracle 在 2013 年 9 月提供了一个修正，作为 Java 7u40 的一部分，包含了类可见性的检查，它会对比预期类型和传入类型的 ClassLoader，对比方式如下：

如果两个 ClassLoader 相同的话，那么按照定义这两个类型是完全兼容的；
如果其中一个 ClassLoader 是另一个 ClassLoader 的父加载器，那么它认为这两个类是通过正常的 ClassLoader 层级结构加载的，因此将其视为相等是安全的。

　　在第二项检查中，Security Explorations 发现 exploit 稍加修改就可能继续有效。首先，用于仿造类的自定义 ClassLoader 将目标 ClassLoader 设置为它的父类加载器，这可以通过 API 以参数的方式进行设置：

URLClassLoader lookup_CL = URLClassLoader.newInstance (urlArray， member_CL);

Java反射库中的安全漏洞在30个月后终于修复了

　　通过该机制将自定义的 ClassLoader 作为等级结构的一部分，来源：Security Explorations。

　　然后，鉴于 ClassLoader 的默认行为是将加载类的任务委托给它的父加载器，攻击者就需要确保父 ClassLoader 无法加载到这个类，这样他们自定义的 ClassLoader 就能发挥作用了。借助 Java 以网络方法加载类的过程，这种攻击模式得到了印证：如果这个类通过 URL 位置的方式来进行定义的话，父 ClassLoader 将会试图连接相关的服务器并获取这个类的代码，此时，预先构建好的 HTTP 服务器可以返回 404 NOT FOUND 错误，让父 ClassLoader 加载这个类出现失败，因此就会将控制权转移给自定义的 ClassLoader。

Java反射库中的安全漏洞在30个月后终于修复了

　　
　　通过自定义的 HTTP 服务器，强制父 ClassLoader 加载类失败之后的代码流，来源：Security Explorations。

　　当这个缺陷 2016 年 3 月重新爆出时，当时最新的可用版本是 8u74，这个版本被证明是有漏洞的，Oracle 在8u77中为其提供了修正。但是，在 8u77 的发布说明中，这个漏洞依然描述为“会影响桌面设备上，Web 浏览器中所运行的 JavaSE[并且]不会影响到 Java 部署环境，比如典型的服务器或独立部署的桌面应用”，但是事实证明，它还是会影响服务器配置以及 Google App Engine 的 Java 环境。

　　修正：2016 年 4 月 29 日

　　本文错误地认为这个漏洞在 8u77、8u91 和 8u92 版本中依然存在，实际上，在 8u77 中它已经得到了修正。在 8u77 的发布说明中将其描述为对 CVE-2016-0636的修正，具体描述是这样的“未指明的漏洞[...]借助 Hotspot 子组件中未知的感染内容”并且没有包含对本文中所提及的 CVE-2013-5838的明确引用。但是，Security Explorations 指出 CVE-2016-0636 是针对 Issue 69 的一个 CVE 编号，而 Issue 69 是他们自己代指最初 CVE-2013-5838 的一种方式。（在本文英文原文的评论区，讨论了该问题解决的相关过程，感兴趣的读者可以访问原文查看。——译者注）

正文到此结束