?咨詢郵箱：
?咨詢熱線：
軟件開發Java反射庫中的安全漏洞在30個月后終于修復了，2013年7月，安全組織Security Explorations發現了Java 7u25中的一個安全漏洞，通過這個漏洞攻擊者可以完全擺脫Java沙箱。Oracle在更新的7u40中包含了一個補丁，但是據Security Explorations 在今年早些時候聲稱，這個補丁僅僅在理念上對其進行了修正，對代碼稍加修改之后，依然可以利用這個漏洞。另外，隨后的研究表明這個漏洞甚至比較初報道的更加嚴重。在這個問題公開之后，Oracle發布了一個補丁，作為8u77的一部分。
這個漏洞可以在新的反射庫中找到，該庫從Java 7以后均可以使用，更具體來講，是在使用新的MethodHandle類動態訪問和調用方法的時候。它與不同ClassLoader加載類的方式有關。要理解這個問題，需要一些基本的知識，這些知識涉及到Java ClassLoader的工作方式， 因為類加載是在Java中大家了解較少的領域之一，所以在闡述這個問題本身之前，我們會首先概述一下這個理念。
Java ClassLoaderJava能夠在運行時從各種來源動態加載代碼。這種功能是通過一系列名為ClassLoader的特殊類來實現的。標準的Java實現會提供多個ClassLoader來加載類，它們能夠從文件系統、URL或壓縮文件等位置加載類，不過Java也為開發人員提供了創建自定義ClassLoader的能力，以應對個性化的需求。與ClassLoader交互的常見方式是調用其loadClass(String)方法，這個方法會接受類的名稱，如果能夠找到的話，就會返回相關的Class對象，如果找不到的話，就會拋出ClassNotFoundException異常。在Java應用中的每個類都是通過某個ClassLoader按照這種方式加載的。
通過設置父ClassLoader，這些不同的ClassLoader能夠互相連接起來，形成一個層級的結構。如果沒有設置父ClassLoader的話，那么父ClassLoader默認將會設置為加載該ClassLoader的那個類加載器(ClassLoader本身也是類，因此也需要通過某個ClassLoader來進行加載)。如果提供了父ClassLoader的話，那么ClassLoader的默認行為就是將加載所請求類的任務委托給它的父加載器，只有父加載器(或祖父加載器)無法加載這個類的時候，這個ClassLoader本身才會試圖加載所請求的類。但是，自定義加載器的創建者并非強制性要求遵循這種默認行為，他們完全可以選擇實現不同的行為。當Java應用啟動的時候，如下的ClassLoader將會按照順序發揮作用：Bootstrap ClassLoader：JVM本身的一部分，因此在每個JVM中，它的實現都是特有的。這個ClassLoader沒有父ClassLoader，它用于加載java.lang包下的核心類。
Extension ClassLoader：負責加載擴展庫中的類，在每個Java安裝環境下可能會有所差別。Extension ClassLoader將會加載java.ext.dirs變量所指定路徑下的所有內容。
Application ClassLoader：負責加載應用程序的主類以及所有位于應用類路徑下的類。
Custom ClassLoader：應用程序中使用的所有其他的ClassLoader。它是可選的，根據應用的情況不同，它可能并不存在。
在運行時，使用自定義的ClassLoader動態加載類為很多的應用創造了可能性，否則的話，有些功能可能是無法實現的，不過，遺憾的是，它也造成了很多的安全問題，尤其是在類仿造(class impersonation)方面。理論上，開發人員可以創建一個自定義的ClassLoader，讓它來加載原始類java.lang.Object的一個模擬實現，并在應用程序中使用這個自定義的對象。這可能會在兩個方面引發安全問題：這個自定義的對象能夠訪問java.lang包下所有包范圍內可見的類內容;其次，這個自定義的Object會被JVM作為標準的Object對象，因此會將其作為由Java實現的可信任的類。為了保護Java以應對這些安全問題，Java類要通過三個屬性來進行識別：類名、包以及ClassLoader的引用。
如果兩個不同的類具有相同的類名和包名，但是由不同的ClassLoader所加載的話，Java會認為它們是不相等的，在它們兩者之間進行賦值的話，將會導致ClassCastException異常。這樣的話，就能保護環境免受類仿造的攻擊。部分修復以及由此導致的漏洞Security Explorations較早報告了這個漏洞，并將其歸類為CVE-2013-5838，這個漏洞可以描述為，當通過Method Handle調用方法時，對于被調用方法的那個類，它的ClassLoader并沒有進行檢查，這意味著攻擊者可以按照上文所述的方法進行類的仿造。
展現原始漏洞的代碼樣例，目標類的ClassLoader并沒有進行檢查;來源：Security Explorations。Oracle在2013年9月提供了一個修正，作為Java 7u40的一部分，包含了類可見性的檢查，它會對比預期類型和傳入類型的ClassLoader，對比方式如下：如果兩個ClassLoader相同的話，那么按照定義這兩個類型是完全兼容的;
如果其中一個ClassLoader是另一個ClassLoader的父加載器，那么它認為這兩個類是通過正常的ClassLoader層級結構加載的，因此將其視為相等是安全的。
在第二項檢查中，Security Explorations發現exploit稍加修改就可能繼續有效。首先，用于仿造類的自定義ClassLoader將目標ClassLoader設置為它的父類加載器，這可以通過API以參數的方式進行設置：URLClassLoader lookup_CL = URLClassLoader.newInstance(urlArray, member_CL);
通過該機制將自定義的ClassLoader作為等級結構的一部分，來源：Security Explorations。然后，鑒于ClassLoader的默認行為是將加載類的任務委托給它的父加載器，攻擊者就需要確保父ClassLoader無法加載到這個類，這樣他們自定義的ClassLoader就能發揮作用了。借助Java以網絡方法加載類的過程，這種攻擊模式得到了印證：如果這個類通過URL位置的方式來進行定義的話，父ClassLoader將會試圖連接相關的服務器并獲取這個類的代碼，此時，預先構建好的HTTP服務器可以返回404 NOT FOUND錯誤，讓父ClassLoader加載這個類出現失敗，因此就會將控制權轉移給自定義的ClassLoader。
通過自定義的HTTP服務器，強制父ClassLoader加載類失敗之后的代碼流，來源：Security Explorations。當這個缺陷2016年3月重新爆出時，當時較新的可用版本是8u74，這個版本被證明是有漏洞的，Oracle在8u77中為其提供了修正。但是，在8u77的發布說明中，這個漏洞依然描述為“會影響桌面設備上，Web瀏覽器中所運行的JavaSE[并且]不會影響到Java部署環境，比如典型的服務器或獨立部署的桌面應用”，但是事實證明，它還是會影響服務器配置以及Google App Engine的Java環境。修正：2016年4月29日本文錯誤地認為這個漏洞在8u77、8u91和8u92版本中依然存在，實際上，在8u77中它已經得到了修正。在8u77的發布說明中將其描述為對CVE-2016-0636的修正，具體描述是這樣的“未指明的漏洞[...]借助Hotspot子組件中未知的感染內容”并且沒有包含對本文中所提及的CVE-2013-5838的明確引用。但是，Security Explorations指出 CVE-2016-0636是針對Issue 69的一個CVE編號，而Issue 69是他們自己代指較初CVE-2013-5838的一種方式。(在本文英文原文的評論區，討論了該問題解決的相關過程，感興趣的讀者可以訪問原文查看。——譯者注)