全国服务热线:
0592-5794349
当前位置:首页> 新闻中心

软件开发Java反射库中的安全漏洞最终在30个月后得到修复。

* 来源: * 作者: * 发表时间: 2019-08-19 0:13:58 * 浏览: 63
软件开发Java反射库中的安全漏洞最终在30个月内得到修复。 2013年7月,安全组织SecurityExplorations在Java7u25中发现了一个安全漏洞,攻击者可以通过该漏洞完全摆脱Java沙箱。 Oracle在更新的7u40中包含了一个补丁,但根据今年早些时候的SecurityExplorations,声称该补丁仅在概念上被修改,并且在对代码进行微小更改后仍然可以利用该漏洞。此外,随后的研究表明,这个漏洞比初始报告更严重。问题发布后,Oracle发布了一个补丁,作为8u77的一部分。此漏洞可以在新的反射库中找到,该库可以从Java 7及更高版本获得,更具体地说,在使用新的MethodHandle类动态访问和调用方法时。它与不同的ClassLoader加载类的方式有关。要理解这个问题,你需要一些关于JavaClassLoader如何工作的基本知识,因为类加载是Java中不太知名的领域之一,所以在我们解释问题本身之前,我们将首先概述这一点。理念。 JavaClassLoaderJava在运行时动态加载来自各种源的代码。此功能通过一系列名为ClassLoader的特殊类实现。标准Java实现提供了多个ClassLoader来加载类,这些类可以从文件系统,URL或zip文件加载类,但Java还为开发人员提供了创建自定义ClassLoader以处理个性化需求的能力。与ClassLoader交互的常用方法是调用其loadClass(String)方法,该方法接受类的名称。如果找到它,它将返回关联的Class对象。如果未找到,则会抛出ClassNotFoundException。 Java应用程序中的每个类都通过ClassLoader以这种方式加载。通过设置父ClassLoader,这些不同的ClassLoader可以相互连接以形成分层结构。如果未设置父ClassLoader,则父ClassLoader将被设置为默认加载ClassLoader的类加载器(ClassLoader本身也是一个类,因此需要由ClassLoader加载)。如果提供了父ClassLoader,则ClassLoader的默认行为是将将所请求的类加载到其父加载器的任务。只有父加载器(或祖父加载器)无法加载类时,才会加载此classLoader本身。尝试加载请求的类。但是,自定义加载器的创建者没有义务遵循此默认行为,他们可以选择实现不同的行为。启动Java应用程序时,以下ClassLoader将按顺序工作:BootstrapClassLoader:JVM本身的一部分,因此它的实现在每个JVM中都是唯一的。这个ClassLoader没有父ClassLoader,它用于加载java.lang包下的核心类。 ExtensionClassLoader:负责加载扩展库中的类,这可能在每个Java安装环境中有所不同。 ExtensionClassLoader将加载java.ext.dirs变量指定的路径下的所有内容。 ApplicationClassLoader:负责加载应用程序的主类以及位于应用程序类路径下的所有类。 CustomClassLoader:应用程序中使用的所有其他ClassLoader。它是可选的,可能不存在,具体取决于应用程序。在运行时,使用自定义ClassLoader动态加载类可以为许多应用程序创建可能性。否则,某些功能可能无法实现,但遗憾的是,它还会产生许多安全问题,尤其是在类模拟中。理论上,开发人员可以创建一个自定义ClassLoader,用于加载原始类java.lang.Object的模拟实现,并在应用程序中使用此自定义对象。这可能会以两种方式引发安全问题:此自定义对象可以访问java.lang包下所有包中可见的类的内容,其次,自定义对象将被JVM用作标准Object对象,因此请考虑它作为在Java中实现的受信任类。为了保护Java免受这些安全问题的影响,Java类由三个属性标识:类名,包和对ClassLoader的引用。如果两个不同的类具有相同的类名和包name,但是由不同的ClassLoader加载,Java会认为它们是不相等的。在它们之间进行分配将导致ClassCastException。通过这种方式,可以保护环境免受伪造攻击。部分修复和由此产生的漏洞SecurityExplorations早先报告了此漏洞,并将其归类为CVE-2013-5838,这个漏洞可以通过MethodHandle调用方法时描述,对于被调用方法的类,不检查ClassLoader,意味着攻击者可以执行如上所述的类复制。显示原始漏洞的示例代码,未检查目标类的ClassLoader,source:SecurityExplorations。 Oracle在2013年9月提供了一个修补程序,作为Java7u40的一部分,其中包括一个类可见性检查,它将预期类型与传入类型的ClassLoader进行比较,如下所示:如果两个ClassLoader相同,那么根据定义这两种类型是完全兼容的。如果其中一个ClassLoader是另一个ClassLoader的父加载器,那么它会认为这两个类是通过普通的ClassLoader层次结构加载的,因此将它们视为相等是安全的。在第二次检查中,SecurityExplorations发现漏洞利用可能会继续进行微小的修改。首先,伪类的自定义ClassLoader将目标ClassLoader设置为其父类加载器,可以通过API设置参数:URLClassLoaderlookup_CL = URLClassLoader.newInstance(urlArray,member_CL),这将由此机制自定义。 ClassLoader是层次结构的一部分,源:SecurityExplorations。然后,由于ClassLoader的默认行为是将加载类的任务委托给其父加载器,因此攻击者需要确保不能将父ClassLoader加载到类中,以便它们的自定义ClassLoader可以工作。这种在网络方法中通过Java攻击类的方法得到了确认:如果类是由URL位置定义的,则父类ClassLoader将尝试连接到相关服务器并获取类的代码。预构建的HTTP服务器可以返回404NOTFOUND错误,导致父ClassLoader无法加载类,从而将控制转移到自定义ClassLoader。强制父类ClassLoader在类失败后通过自定义HTTP服务器加载代码流,源:SecurityExplorations。当这个漏洞在2016年3月重新出现时,当时较新的版本是8u74,这被证明是易受攻击的,Oracle在8u77中提供了更正。但是,在8u77的发行说明中,此漏洞仍被描述为ldquo,它影响在Web浏览器上运行的JavaSE,并且不会影响Java部署环境,例如典型服务器或独立桌面。应用程序,但事实证明它仍然影响到GoogleAppEngine的服务器配置和Java环境。修复:2016年4月29日,本文错误地认为此漏洞仍存在于8u77,8u91和8u92版本中。事实上,它已在8u77修复。在8u77的发行说明中,它被描述为CVE-2016-0636的修改,具体描述是这样的,未指定的漏洞[...]通过Hotspot子组件中未知的受感染内容,并且不包含在本文。明确提到上述CVE-2013-5838。但是,SecurityExplorations指出CVE-2016-0636是Issue69的CVE编号,而Issue69是他们引用CVE-2013-5838的一种方式。 (在原始英文文本的评论部分,讨论了解决问题的相关过程。有兴趣的读者可以访问原文。 mdash,mdash,译者注)