軟件開(kāi)發(fā)Java反射庫(kù)中的安全漏洞在30個(gè)月后終于修復(fù)了，2013年7月，安全組織Security Explorations發(fā)現(xiàn)了Java 7u25中的一個(gè)安全漏洞，通過(guò)這個(gè)漏洞攻擊者可以完全擺脫Java沙箱。Oracle在更新的7u40中包含了一個(gè)補(bǔ)丁，但是據(jù)Security Explorations 在今年早些時(shí)候聲稱，這個(gè)補(bǔ)丁僅僅在理念上對(duì)其進(jìn)行了修正，對(duì)代碼稍加修改之后，依然可以利用這個(gè)漏洞。另外，隨后的研究表明這個(gè)漏洞甚至比較初報(bào)道的更加嚴(yán)重。在這個(gè)問(wèn)題公開(kāi)之后，Oracle發(fā)布了一個(gè)補(bǔ)丁，作為8u77的一部分。

　　這個(gè)漏洞可以在新的反射庫(kù)中找到，該庫(kù)從Java 7以后均可以使用，更具體來(lái)講，是在使用新的MethodHandle類動(dòng)態(tài)訪問(wèn)和調(diào)用方法的時(shí)候。它與不同ClassLoader加載類的方式有關(guān)。要理解這個(gè)問(wèn)題，需要一些基本的知識(shí)，這些知識(shí)涉及到Java ClassLoader的工作方式， 因?yàn)轭惣虞d是在Java中大家了解較少的領(lǐng)域之一，所以在闡述這個(gè)問(wèn)題本身之前，我們會(huì)首先概述一下這個(gè)理念。

　　Java ClassLoaderJava能夠在運(yùn)行時(shí)從各種來(lái)源動(dòng)態(tài)加載代碼。這種功能是通過(guò)一系列名為ClassLoader的特殊類來(lái)實(shí)現(xiàn)的。標(biāo)準(zhǔn)的Java實(shí)現(xiàn)會(huì)提供多個(gè)ClassLoader來(lái)加載類，它們能夠從文件系統(tǒng)、URL或壓縮文件等位置加載類，不過(guò)Java也為開(kāi)發(fā)人員提供了創(chuàng)建自定義ClassLoader的能力，以應(yīng)對(duì)個(gè)性化的需求。與ClassLoader交互的常見(jiàn)方式是調(diào)用其loadClass(String)方法，這個(gè)方法會(huì)接受類的名稱，如果能夠找到的話，就會(huì)返回相關(guān)的Class對(duì)象，如果找不到的話，就會(huì)拋出ClassNotFoundException異常。在Java應(yīng)用中的每個(gè)類都是通過(guò)某個(gè)ClassLoader按照這種方式加載的。

　　通過(guò)設(shè)置父ClassLoader，這些不同的ClassLoader能夠互相連接起來(lái)，形成一個(gè)層級(jí)的結(jié)構(gòu)。如果沒(méi)有設(shè)置父ClassLoader的話，那么父ClassLoader默認(rèn)將會(huì)設(shè)置為加載該ClassLoader的那個(gè)類加載器(ClassLoader本身也是類，因此也需要通過(guò)某個(gè)ClassLoader來(lái)進(jìn)行加載)。如果提供了父ClassLoader的話，那么ClassLoader的默認(rèn)行為就是將加載所請(qǐng)求類的任務(wù)委托給它的父加載器，只有父加載器(或祖父加載器)無(wú)法加載這個(gè)類的時(shí)候，這個(gè)ClassLoader本身才會(huì)試圖加載所請(qǐng)求的類。但是，自定義加載器的創(chuàng)建者并非強(qiáng)制性要求遵循這種默認(rèn)行為，他們完全可以選擇實(shí)現(xiàn)不同的行為。當(dāng)Java應(yīng)用啟動(dòng)的時(shí)候，如下的ClassLoader將會(huì)按照順序發(fā)揮作用：Bootstrap ClassLoader：JVM本身的一部分，因此在每個(gè)JVM中，它的實(shí)現(xiàn)都是特有的。這個(gè)ClassLoader沒(méi)有父ClassLoader，它用于加載java.lang包下的核心類。

　　Extension ClassLoader：負(fù)責(zé)加載擴(kuò)展庫(kù)中的類，在每個(gè)Java安裝環(huán)境下可能會(huì)有所差別。Extension ClassLoader將會(huì)加載java.ext.dirs變量所指定路徑下的所有內(nèi)容。

　　Application ClassLoader：負(fù)責(zé)加載應(yīng)用程序的主類以及所有位于應(yīng)用類路徑下的類。

　　Custom ClassLoader：應(yīng)用程序中使用的所有其他的ClassLoader。它是可選的，根據(jù)應(yīng)用的情況不同，它可能并不存在。

　　在運(yùn)行時(shí)，使用自定義的ClassLoader動(dòng)態(tài)加載類為很多的應(yīng)用創(chuàng)造了可能性，否則的話，有些功能可能是無(wú)法實(shí)現(xiàn)的，不過(guò)，遺憾的是，它也造成了很多的安全問(wèn)題，尤其是在類仿造(class impersonation)方面。理論上，開(kāi)發(fā)人員可以創(chuàng)建一個(gè)自定義的ClassLoader，讓它來(lái)加載原始類java.lang.Object的一個(gè)模擬實(shí)現(xiàn)，并在應(yīng)用程序中使用這個(gè)自定義的對(duì)象。這可能會(huì)在兩個(gè)方面引發(fā)安全問(wèn)題：這個(gè)自定義的對(duì)象能夠訪問(wèn)java.lang包下所有包范圍內(nèi)可見(jiàn)的類內(nèi)容;其次，這個(gè)自定義的Object會(huì)被JVM作為標(biāo)準(zhǔn)的Object對(duì)象，因此會(huì)將其作為由Java實(shí)現(xiàn)的可信任的類。為了保護(hù)Java以應(yīng)對(duì)這些安全問(wèn)題，Java類要通過(guò)三個(gè)屬性來(lái)進(jìn)行識(shí)別：類名、包以及ClassLoader的引用。

　　如果兩個(gè)不同的類具有相同的類名和包名，但是由不同的ClassLoader所加載的話，Java會(huì)認(rèn)為它們是不相等的，在它們兩者之間進(jìn)行賦值的話，將會(huì)導(dǎo)致ClassCastException異常。這樣的話，就能保護(hù)環(huán)境免受類仿造的攻擊。部分修復(fù)以及由此導(dǎo)致的漏洞Security Explorations較早報(bào)告了這個(gè)漏洞，并將其歸類為CVE-2013-5838，這個(gè)漏洞可以描述為，當(dāng)通過(guò)Method Handle調(diào)用方法時(shí)，對(duì)于被調(diào)用方法的那個(gè)類，它的ClassLoader并沒(méi)有進(jìn)行檢查，這意味著攻擊者可以按照上文所述的方法進(jìn)行類的仿造。

　　展現(xiàn)原始漏洞的代碼樣例，目標(biāo)類的ClassLoader并沒(méi)有進(jìn)行檢查;來(lái)源：Security Explorations。Oracle在2013年9月提供了一個(gè)修正，作為Java 7u40的一部分，包含了類可見(jiàn)性的檢查，它會(huì)對(duì)比預(yù)期類型和傳入類型的ClassLoader，對(duì)比方式如下：如果兩個(gè)ClassLoader相同的話，那么按照定義這兩個(gè)類型是完全兼容的;

　　如果其中一個(gè)ClassLoader是另一個(gè)ClassLoader的父加載器，那么它認(rèn)為這兩個(gè)類是通過(guò)正常的ClassLoader層級(jí)結(jié)構(gòu)加載的，因此將其視為相等是安全的。

　　在第二項(xiàng)檢查中，Security Explorations發(fā)現(xiàn)exploit稍加修改就可能繼續(xù)有效。首先，用于仿造類的自定義ClassLoader將目標(biāo)ClassLoader設(shè)置為它的父類加載器，這可以通過(guò)API以參數(shù)的方式進(jìn)行設(shè)置：URLClassLoader lookup_CL = URLClassLoader.newInstance(urlArray, member_CL);

　　通過(guò)該機(jī)制將自定義的ClassLoader作為等級(jí)結(jié)構(gòu)的一部分，來(lái)源：Security Explorations。然后，鑒于ClassLoader的默認(rèn)行為是將加載類的任務(wù)委托給它的父加載器，攻擊者就需要確保父ClassLoader無(wú)法加載到這個(gè)類，這樣他們自定義的ClassLoader就能發(fā)揮作用了。借助Java以網(wǎng)絡(luò)方法加載類的過(guò)程，這種攻擊模式得到了印證：如果這個(gè)類通過(guò)URL位置的方式來(lái)進(jìn)行定義的話，父ClassLoader將會(huì)試圖連接相關(guān)的服務(wù)器并獲取這個(gè)類的代碼，此時(shí)，預(yù)先構(gòu)建好的HTTP服務(wù)器可以返回404 NOT FOUND錯(cuò)誤，讓父ClassLoader加載這個(gè)類出現(xiàn)失敗，因此就會(huì)將控制權(quán)轉(zhuǎn)移給自定義的ClassLoader。

　　通過(guò)自定義的HTTP服務(wù)器，強(qiáng)制父ClassLoader加載類失敗之后的代碼流，來(lái)源：Security Explorations。當(dāng)這個(gè)缺陷2016年3月重新爆出時(shí)，當(dāng)時(shí)較新的可用版本是8u74，這個(gè)版本被證明是有漏洞的，Oracle在8u77中為其提供了修正。但是，在8u77的發(fā)布說(shuō)明中，這個(gè)漏洞依然描述為“會(huì)影響桌面設(shè)備上，Web瀏覽器中所運(yùn)行的JavaSE[并且]不會(huì)影響到Java部署環(huán)境，比如典型的服務(wù)器或獨(dú)立部署的桌面應(yīng)用”，但是事實(shí)證明，它還是會(huì)影響服務(wù)器配置以及Google App Engine的Java環(huán)境。修正：2016年4月29日本文錯(cuò)誤地認(rèn)為這個(gè)漏洞在8u77、8u91和8u92版本中依然存在，實(shí)際上，在8u77中它已經(jīng)得到了修正。在8u77的發(fā)布說(shuō)明中將其描述為對(duì)CVE-2016-0636的修正，具體描述是這樣的“未指明的漏洞[...]借助Hotspot子組件中未知的感染內(nèi)容”并且沒(méi)有包含對(duì)本文中所提及的CVE-2013-5838的明確引用。但是，Security Explorations指出 CVE-2016-0636是針對(duì)Issue 69的一個(gè)CVE編號(hào)，而Issue 69是他們自己代指較初CVE-2013-5838的一種方式。(在本文英文原文的評(píng)論區(qū)，討論了該問(wèn)題解決的相關(guān)過(guò)程，感興趣的讀者可以訪問(wèn)原文查看。——譯者注)