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

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

Java ClassLoader

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

通過設(shè)置父ClassLoader，這些不同的ClassLoader能夠互相連接起來，形成一個層級的結(jié)構(gòu)。如果沒有設(shè)置父ClassLoader的話，那么父ClassLoader默認(rèn)將會設(shè)置為加載該ClassLoader的那個類加載器（ClassLoader本身也是類，因此也需要通過某個ClassLoader來進(jìn)行加載）。如果提供了父ClassLoader的話，那么ClassLoader的默認(rèn)行為就是將加載所請求類的任務(wù)委托給它的父加載器，只有父加載器（或祖父加載器）無法加載這個類的時候，這個ClassLoader本身才會試圖加載所請求的類。但是，自定義加載器的創(chuàng)建者并非強(qiáng)制性要求遵循這種默認(rèn)行為，他們完全可以選擇實(shí)現(xiàn)不同的行為。

當(dāng)Java應(yīng)用啟動的時候，如下的ClassLoader將會按照順序發(fā)揮作用：

Bootstrap ClassLoader：JVM本身的一部分，因此在每個JVM中，它的實(shí)現(xiàn)都是特有的。這個ClassLoader沒有父ClassLoader，它用于加載java.lang包下的核心類。 Extension ClassLoader：負(fù)責(zé)加載擴(kuò)展庫中的類，在每個Java安裝環(huán)境下可能會有所差別。Extension ClassLoader將會加載java.ext.dirs變量所指定路徑下的所有內(nèi)容。 Application ClassLoader：負(fù)責(zé)加載應(yīng)用程序的主類以及所有位于應(yīng)用類路徑下的類。 Custom ClassLoader：應(yīng)用程序中使用的所有其他的ClassLoader。它是可選的，根據(jù)應(yīng)用的情況不同，它可能并不存在。

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

為了保護(hù)Java以應(yīng)對這些安全問題，Java類要通過三個屬性來進(jìn)行識別：類名、包以及ClassLoader的引用。如果兩個不同的類具有相同的類名和包名，但是由不同的ClassLoader所加載的話，Java會認(rèn)為它們是不相等的，在它們兩者之間進(jìn)行賦值的話，將會導(dǎo)致ClassCastException異常。這樣的話，就能保護(hù)環(huán)境免受類仿造的攻擊。

部分修復(fù)以及由此導(dǎo)致的漏洞

Security Explorations最早報告了這個漏洞，并將其歸類為CVE-2013-5838，這個漏洞可以描述為，當(dāng)通過Method Handle調(diào)用方法時，對于被調(diào)用方法的那個類，它的ClassLoader并沒有進(jìn)行檢查，這意味著攻擊者可以按照上文所述的方法進(jìn)行類的仿造。

展現(xiàn)原始漏洞的代碼樣例，目標(biāo)類的ClassLoader并沒有進(jìn)行檢查；來源：Security Explorations。

Oracle在2013年9月提供了一個修正，作為Java 7u40的一部分，包含了類可見性的檢查，它會對比預(yù)期類型和傳入類型的ClassLoader，對比方式如下：

如果兩個ClassLoader相同的話，那么按照定義這兩個類型是完全兼容的； 如果其中一個ClassLoader是另一個ClassLoader的父加載器，那么它認(rèn)為這兩個類是通過正常的ClassLoader層級結(jié)構(gòu)加載的，因此將其視為相等是安全的。

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

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

通過該機(jī)制將自定義的ClassLoader作為等級結(jié)構(gòu)的一部分，來源：Security Explorations。

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

　　通過自定義的HTTP服務(wù)器，強(qiáng)制父ClassLoader加載類失敗之后的代碼流，來源：Security Explorations。

當(dāng)這個缺陷2016年3月重新爆出時，當(dāng)時最新的可用版本是8u74，這個版本被證明是有漏洞的，Oracle在8u77中為其提供了修正。但是，在8u77的發(fā)布說明中，這個漏洞依然描述為“會影響桌面設(shè)備上，Web瀏覽器中所運(yùn)行的JavaSE[并且]不會影響到Java部署環(huán)境，比如典型的服務(wù)器或獨(dú)立部署的桌面應(yīng)用”，但是事實(shí)證明，它還是會影響服務(wù)器配置以及Google App Engine的Java環(huán)境。

修正：2016年4月29日

本文錯誤地認(rèn)為這個漏洞在8u77、8u91和8u92版本中依然存在，實(shí)際上，在8u77中它已經(jīng)得到了修正。在8u77的發(fā)布說明中將其描述為對CVE-2016-0636的修正，具體描述是這樣的“未指明的漏洞[...]借助Hotspot子組件中未知的感染內(nèi)容”并且沒有包含對本文中所提及的CVE-2013-5838的明確引用。但是，Security Explorations指出 CVE-2016-0636是針對Issue 69的一個CVE編號，而Issue 69是他們自己代指最初CVE-2013-5838的一種方式。（在本文英文原文的評論區(qū)，討論了該問題解決的相關(guān)過程，感興趣的讀者可以訪問原文查看。——譯者注）