| 注册
请输入搜索内容

热门搜索

Java Linux MySQL PHP JavaScript Hibernate jQuery Nginx
ShaPadgett
8年前发布

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

   <p>2013年7月,安全组织Security Explorations发现了 <a href="/misc/goto?guid=4959673212959424652" rel="nofollow,noindex">Java 7u25中的一个安全漏洞</a> ,通过这个漏洞攻击者可以完全摆脱Java沙箱。Oracle在更新的7u40中包含了一个补丁,但是据Security Explorations <a href="/misc/goto?guid=4959673213036671313" rel="nofollow,noindex">在今年早些时候声称</a> ,这个补丁仅仅在理念上对其进行了修正,对代码稍加修改之后,依然可以利用这个漏洞。另外,随后的研究表明这个漏洞甚至比最初报道的更加严重。在这个问题公开之后,Oracle发布了一个补丁,作为 <a href="/misc/goto?guid=4959673213127274735" rel="nofollow,noindex">8u77</a> 的一部分。</p>    <p>这个漏洞可以在新的反射库中找到,该库从Java 7以后均可以使用,更具体来讲,是在使用新的 <a href="/misc/goto?guid=4959673213203673604" rel="nofollow,noindex">MethodHandle</a> 类动态访问和调用方法的时候。它与不同ClassLoader加载类的方式有关。要理解这个问题,需要一些基本的知识,这些知识涉及到Java ClassLoader的工作方式, 因为类加载是在Java中大家了解最少的领域之一,所以在阐述这个问题本身之前,我们会首先概述一下这个理念。</p>    <p>Java ClassLoader</p>    <p>Java能够在运行时从各种来源动态加载代码。这种功能是通过一系列名为ClassLoader的特殊类来实现的。标准的Java实现会提供多个ClassLoader来加载类,它们能够从文件系统、URL或压缩文件等位置加载类,不过Java也为开发人员提供了创建自定义ClassLoader的能力,以应对个性化的需求。与ClassLoader交互的常见方式是调用其loadClass(String)方法,这个方法会接受类的名称,如果能够找到的话,就会返回相关的Class对象,如果找不到的话,就会抛出ClassNotFoundException异常。在Java应用中的每个类都是通过某个ClassLoader按照这种方式加载的。</p>    <p>通过设置父ClassLoader,这些不同的ClassLoader能够互相连接起来,形成一个层级的结构。如果没有设置父ClassLoader的话,那么父ClassLoader默认将会设置为加载该ClassLoader的那个类加载器(ClassLoader本身也是类,因此也需要通过某个ClassLoader来进行加载)。如果提供了父ClassLoader的话,那么ClassLoader的默认行为就是将加载所请求类的任务委托给它的父加载器,只有父加载器(或祖父加载器)无法加载这个类的时候,这个ClassLoader本身才会试图加载所请求的类。但是,自定义加载器的创建者并非强制性要求遵循这种默认行为,他们完全可以选择实现不同的行为。</p>    <p>当Java应用启动的时候,如下的ClassLoader将会按照顺序发挥作用:</p>    <ol>     <li>Bootstrap ClassLoader:JVM本身的一部分,因此在每个JVM中,它的实现都是特有的。这个ClassLoader没有父ClassLoader,它用于加载java.lang包下的核心类。</li>     <li>Extension ClassLoader:负责加载扩展库中的类,在每个Java安装环境下可能会有所差别。Extension ClassLoader将会加载java.ext.dirs变量所指定路径下的所有内容。</li>     <li>Application ClassLoader:负责加载应用程序的主类以及所有位于应用类路径下的类。</li>     <li>Custom ClassLoader:应用程序中使用的所有其他的ClassLoader。它是可选的,根据应用的情况不同,它可能并不存在。</li>    </ol>    <p>在运行时,使用自定义的ClassLoader动态加载类为很多的应用创造了可能性,否则的话,有些功能可能是无法实现的,不过,遗憾的是,它也造成了很多的安全问题,尤其是在类仿造(class impersonation)方面。理论上,开发人员可以创建一个自定义的ClassLoader,让它来加载原始类java.lang.Object的一个模拟实现,并在应用程序中使用这个自定义的对象。这可能会在两个方面引发安全问题:这个自定义的对象能够访问java.lang包下所有包范围内可见的类内容;其次,这个自定义的Object会被JVM作为标准的Object对象,因此会将其作为由Java实现的可信任的类。</p>    <p>为了保护Java以应对这些安全问题,Java类要通过三个属性来进行识别:类名、包以及ClassLoader的引用。如果两个不同的类具有相同的类名和包名,但是由不同的ClassLoader所加载的话,Java会认为它们是不相等的,在它们两者之间进行赋值的话,将会导致ClassCastException异常。这样的话,就能保护环境免受类仿造的攻击。</p>    <p>部分修复以及由此导致的漏洞</p>    <p>Security Explorations最早报告了这个漏洞,并将其归类为 <a href="/misc/goto?guid=4959673213290204657" rel="nofollow,noindex">CVE-2013-5838</a> ,这个漏洞可以描述为,当通过Method Handle调用方法时,对于被调用方法的那个类,它的ClassLoader并没有进行检查,这意味着攻击者可以按照上文所述的方法进行类的仿造。</p>    <p><img src="https://simg.open-open.com/show/29ce2fff13479771a8b41e2d049ff20a.jpg"></p>    <p>展现原始漏洞的代码样例,目标类的ClassLoader并没有进行检查;来源: <a href="/misc/goto?guid=4959673212959424652" rel="nofollow,noindex">Security Explorations</a> 。</p>    <p>Oracle在2013年9月提供了一个修正,作为Java 7u40的一部分,包含了类可见性的检查,它会对比预期类型和传入类型的ClassLoader,对比方式如下:</p>    <ul>     <li>如果两个ClassLoader相同的话,那么按照定义这两个类型是完全兼容的;</li>     <li>如果其中一个ClassLoader是另一个ClassLoader的父加载器,那么它认为这两个类是通过正常的ClassLoader层级结构加载的,因此将其视为相等是安全的。</li>    </ul>    <p>在第二项检查中,Security Explorations发现 <a href="/misc/goto?guid=4959673213386935472" rel="nofollow,noindex">exploit稍加修改就可能继续有效</a> 。首先,用于仿造类的自定义ClassLoader将目标ClassLoader设置为它的父类加载器,这可以通过API以参数的方式进行设置:</p>    <pre>  URLClassLoader lookup_CL = URLClassLoader.newInstance(urlArray, member_CL);</pre>    <p><img src="https://simg.open-open.com/show/c4d56426d6c32b13b1122cae9e617016.jpg"></p>    <p>通过该机制将自定义的ClassLoader作为等级结构的一部分,来源: <a href="/misc/goto?guid=4959673213386935472" rel="nofollow,noindex">Security Explorations</a> 。</p>    <p>然后,鉴于ClassLoader的默认行为是将加载类的任务委托给它的父加载器,攻击者就需要确保父ClassLoader无法加载到这个类,这样他们自定义的ClassLoader就能发挥作用了。借助Java以网络方法加载类的过程,这种攻击模式得到了印证:如果这个类通过URL位置的方式来进行定义的话,父ClassLoader将会试图连接相关的服务器并获取这个类的代码,此时,预先构建好的HTTP服务器可以返回404 NOT FOUND错误,让父ClassLoader加载这个类出现失败,因此就会将控制权转移给自定义的ClassLoader。</p>    <p><img src="https://simg.open-open.com/show/ff3dde6652cfd04ad20f27cfdf8f3c5a.jpg"></p>    <p>通过自定义的HTTP服务器,强制父ClassLoader加载类失败之后的代码流,来源: <a href="/misc/goto?guid=4959673213386935472" rel="nofollow,noindex">Security Explorations</a> 。</p>    <p>当这个缺陷2016年3月重新爆出时,当时最新的可用版本是8u74,这个版本被证明是有漏洞的,Oracle在 <a href="/misc/goto?guid=4959673213127274735" rel="nofollow,noindex">8u77</a> 中为其提供了修正。但是,在8u77的发布说明中,这个漏洞依然描述为“会影响桌面设备上,Web浏览器中所运行的JavaSE[并且]不会影响到Java部署环境,比如典型的服务器或独立部署的桌面应用”,但是事实证明,它还是会影响服务器配置以及Google App Engine的Java环境。</p>    <p>修正:2016年4月29日</p>    <p>本文错误地认为这个漏洞在8u77、8u91和8u92版本中依然存在,实际上,在8u77中它已经得到了修正。在8u77的发布说明中将其描述为对 <a href="/misc/goto?guid=4959673213495426333" rel="nofollow,noindex">CVE-2016-0636</a> 的修正,具体描述是这样的“未指明的漏洞[...]借助Hotspot子组件中未知的感染内容”并且没有包含对本文中所提及的 <a href="/misc/goto?guid=4959673213290204657" rel="nofollow,noindex">CVE-2013-5838</a> 的明确引用。但是,Security Explorations指出 <a href="/misc/goto?guid=4958525664038537402" rel="nofollow,noindex">CVE-2016-0636是针对Issue 69的一个CVE编号</a> ,而Issue 69是他们自己代指最初CVE-2013-5838的一种方式。(在本文英文原文的评论区,讨论了该问题解决的相关过程,感兴趣的读者可以访问原文查看。——译者注)</p>    <p>查看英文原文: <a href="/misc/goto?guid=4959673213614414799" rel="nofollow,noindex">Vulnerability in Java Reflection Library Fixed after 30 Months</a></p>    <p>via: http://www.infoq.com/cn/news/2016/05/java-reflection-vulnerability</p>    
 本文由用户 ShaPadgett 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
 转载本站原创文章,请注明出处,并保留原始链接、图片水印。
 本站是一个以用户分享为主的开源技术平台,欢迎各类分享!
 本文地址:https://www.open-open.com/lib/view/open1463444053277.html
Java 安全漏洞 Java开发