軟件開發Java反射庫中的安全漏洞在30個月後終於修複瞭，2013年7月，安全組織Security Explorations發現瞭Java 7u25中的一個安全漏洞，通過這個漏洞攻擊者可以完全擺脫Java沙箱。Oracle在更新的7u40中包含瞭一個補丁，但是據Security Explorations 在今年早些時候聲稱，這個補丁僅僅在理念上對其進行瞭修正，對代碼稍加修改之後，依然可以利用這個漏洞。另外，随後的研究表明這個漏洞甚至比較初報道的更加嚴重。在這個問題公開之後，Oracle發布瞭一個補丁，作爲8u77的一部分。

　　這個漏洞可以在新的反射庫中找到，該庫從Java 7以後均可以使用，更具體來講，是在使用新的MethodHandle類動态訪問和調用方法的時候。它與不同ClassLoader加載類的方式有關。要理解這個問題，需要一些基本的知識，這些知識涉及到Java ClassLoader的工作方式， 因爲類加載是在Java中大家瞭(le)解較少的領域之一，所以在闡(chǎn)述這個問題本身之前，我們會首先概述一下這個理念。

　　Java ClassLoaderJava能夠在運行時從各種來源動态加載代碼。這種功能是通過一系列名爲ClassLoader的特殊類來實現的。标準的Java實現會提供多個ClassLoader來加載類，它們能夠從文件系統、URL或壓縮文件等位置加載類，不過Java也爲開發人員提供瞭(le)創建自定義ClassLoader的能力，以應對個性化的需求。與ClassLoader交互的常見方式是調用其loadClass(String)方法，這個方法會接受類的名稱(chēng)，如果能夠找到的話，就會返回相關的Class對象，如果找不到的話，就會抛出ClassNotFoundException異常。在Java應用中的每個類都是通過某個ClassLoader按照這種方式加載的。

　　通過設置父ClassLoader，這些不同的ClassLoader能夠互相連接起來，形成一個層級的結構。如果沒有設置父ClassLoader的話，那麽父ClassLoader默認将會設置爲加載該ClassLoader的那個類加載器(ClassLoader本身也是類，因此也需要通過某個ClassLoader來進行加載)。如果提供瞭(le)父ClassLoader的話，那麽ClassLoader的默認行爲就是将加載所請求類的任務委托給它的父加載器，隻有父加載器(或祖父加載器)無法加載這個類的時候，這個ClassLoader本身才會試圖加載所請求的類。但是，自定義加載器的創建者並(bìng)非強制性要求遵循這種默認行爲，他們完全可以選擇實現不同的行爲。當Java應用啓動的時候，如下的ClassLoader将會按照順序發揮作用：Bootstrap ClassLoader：JVM本身的一部分，因此在每個JVM中，它的實現都是特有的。這個ClassLoader沒有父ClassLoader，它用於加載java.lang包下的核心類。

　　Extension ClassLoader：負(fù)責加載擴展庫中的類，在每個Java安裝環境下可能會有所差别。Extension ClassLoader将會加載java.ext.dirs變(biàn)量所指定路徑下的所有内容。

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

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

　　在運行時，使用自定義的ClassLoader動态加載類爲很多的應用創造瞭(le)可能性，否則的話，有些功能可能是無法實現的，不過，遺憾的是，它也造成瞭(le)很多的安全問題，尤其是在類仿造(class impersonation)方面。理論上，開發人員可以創建一個自定義的ClassLoader，讓它來加載原始類java.lang.Object的一個模拟實現，並(bìng)在應用程序中使用這個自定義的對象。這可能會在兩個方面引發安全問題：這個自定義的對象能夠訪問java.lang包下所有包範圍内可見的類内容;其次，這個自定義的Object會被JVM作爲标準的Object對象，因此會将其作爲由Java實現的可信任的類。爲瞭(le)保護Java以應對這些安全問題，Java類要通過三個屬性來進行識别：類名、包以及ClassLoader的引用。

　　如果兩個不同的類具有相同的類名和包名，但是由不同的ClassLoader所加載的話，Java會認爲它們是不相等的，在它們兩者之間進行賦值的話，将會導緻ClassCastException異常。這樣的話，就能保護環境免受類仿造的攻擊。部分修複以及由此導緻的漏洞Security Explorations較早報告瞭這個漏洞，並(bìng)将其歸類爲CVE-2013-5838，這個漏洞可以描述爲，當通過Method Handle調用方法時，對於被調用方法的那個類，它的ClassLoader並(bìng)沒有進行檢查，這意味著(zhe)攻擊者可以按照上文所述的方法進行類的仿造。

　　展現原始漏洞的代碼樣例，目标類的ClassLoader並(bìng)沒有進行檢查;來源：Security Explorations。Oracle在2013年9月提供瞭(le)一個修正，作爲Java 7u40的一部分，包含瞭(le)類可見性的檢查，它會對比預期類型和傳入類型的ClassLoader，對比方式如下：如果兩個ClassLoader相同的話，那麽按照定義這兩個類型是完全兼容的;

　　如果其中一個(gè)ClassLoader是另一個(gè)ClassLoader的父加載器，那麽它認爲這兩個(gè)類是通過正常的ClassLoader層(céng)級結構加載的，因此将其視爲相等是安全的。

　　在第二項檢查中，Security Explorations發現exploit稍加修改就可能繼續有效。首先，用於(yú)仿造類的自定義ClassLoader将目标ClassLoader設置爲它的父類加載器，這可以通過API以參(cān)數的方式進行設置：URLClassLoader lookup_CL = URLClassLoader.newInstance(urlArray, member_CL);

　　通過該機制将自定義的ClassLoader作爲等級結構的一部分，來源：Security Explorations。然後，鑒於ClassLoader的默認行爲是将加載類的任務委托給它的父加載器，攻擊者就需要確保父ClassLoader無法加載到這個類，這樣他們自定義的ClassLoader就能發揮作用瞭(le)。借助Java以網絡方法加載類的過程，這種攻擊模式得到瞭(le)印證：如果這個類通過URL位置的方式來進行定義的話，父ClassLoader将會試圖連接相關的服務器並(bìng)獲取這個類的代碼，此時，預先構建好的HTTP服務器可以返回404 NOT FOUND錯誤，讓父ClassLoader加載這個類出現失敗，因此就會将控制權轉移給自定義的ClassLoader。

　　通過自定義的HTTP服務器，強制父ClassLoader加載類失敗之後的代碼流，來源：Security Explorations。當這個缺陷2016年3月重新爆出時，當時較新的可用版本是8u74，這個版本被證明是有漏洞的，Oracle在8u77中爲其提供瞭(le)修正。但是，在8u77的發布說明中，這個漏洞依然描述爲“會影響桌面設備上，Web浏覽器中所運行的JavaSE[並(bìng)且]不會影響到Java部署環境，比如典型的服務器或獨立部署的桌面應用”，但是事實證明，它還是會影響服務器配置以及Google App Engine的Java環境。修正：2016年4月29日本文錯誤地認爲這個漏洞在8u77、8u91和8u92版本中依然存在，實際上，在8u77中它已經得到瞭(le)修正。在8u77的發布說明中将其描述爲對CVE-2016-0636的修正，具體描述是這樣的“未指明的漏洞[...]借助Hotspot子組件中未知的感染内容”並(bìng)且沒有包含對本文中所提及的CVE-2013-5838的明確引用。但是，Security Explorations指出 CVE-2016-0636是針對Issue 69的一個CVE編号，而Issue 69是他們自己代指較初CVE-2013-5838的一種方式。(在本文英文原文的評論區，讨論瞭(le)該問題解決的相關過程，感興趣的讀者可以訪問原文查看。——譯者注)