的30個月后，終于解決了Java反射庫中用于軟件開發的安全漏洞。 2013年7月，安全組織SecurityExplorations在Java7u25中發現了一個安全漏洞，攻擊者可以通過該漏洞完全擺脫Java沙箱。 Oracle在更新后的7u40中包括了一個補丁程序，但是根據今年早些時候的SecurityExplorations所說，該補丁程序僅在概念上進行了修改，對該代碼進行少量修改后仍然可以利用。此外，后續研究表明，此漏洞比最初報告的漏洞更加嚴重。在此問題公開之后，Oracle作為8u77的一部分發布了一個修補程序。該漏洞可以在新的反射庫中找到，該反射庫可以從Java7開始使用，更具體地說，當使用新的MethodHandle類動態訪問和調用方法時。它與不同的ClassLoader加載類的方式有關。要了解此問題，您需要一些基本知識。該知識與JavaClassLoader的工作方法有關。因為類加載是Java中每個人都不了解的領域之一，所以在解釋問題本身之前，我們將首先對此進行概述。理念。 JavaClassLoaderJava可以在運行時從各種來源動態加載代碼。此功能是通過一系列稱為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將按順序工作：BootstrapClassLoader：JVM本身的一部分，因此其實現在每個JVM中都是唯一的。該ClassLoader沒有父ClassLoader，用于在java.lang包下加載核心類。 ExtensionClassLoader：負責在擴展庫中加載類，在每個Java安裝環境下，類可能有所不同。 ExtensionClassLoader將在java.ext.dirs變量指定的路徑中加載所有內容。 ApplicationClassLoader：負責加載應用程序的主類和位于應用程序類路徑中的所有類。 CustomClassLoader：應用程序中使用的所有其他ClassLoader。它是可選的，根據應用程序可能不存在。在運行時，使用自定義ClassLoader動態加載類為許多應用程序創造了可能性，否則，某些功能可能無法實現，但是不幸的是，這還會引起很多安全問題，尤其是在類模擬中。從理論上講，開發人員可以創建一個自定義的ClassLoader，讓它加載原始類java.lang.Object的模擬實現，并在應用程序中使用此自定義對象。這可能會在兩個方面引起安全問題：此自定義對象可以訪問java.lang包的包范圍中可見的所有類的內容。其次，JVM將使用此自定義對象作為標準Object對象，因此它將其視為用Java實現的受信任類。為了保護Java免受這些安全問題的影響，Java類由三個屬性標識：類名稱，包和對ClassLoader的引用。如果兩個不同的類別具有相同的分類的名稱和包名稱，但是由不同的ClassLoader加載，Java會認為它們是不相等的。在它們之間分配一個值將導致ClassCastException。這樣，您可以保護環境免受假冒攻擊。部分已修復，因此產生的漏洞SecurityExplorations較早報告了此漏洞，并將其分類為CVE-2013-5838。此漏洞可以描述為，當通過MethodHandle調用方法時，對于被調用方法的類，它不會檢查ClassLoader，這意味著攻擊者可以如上所述偽造類。顯示原始漏洞的代碼示例。未檢查目標類的ClassLoader。資料來源：SecurityExplorations。 Oracle在2013年9月提供了一個修復程序。作為Java7u40的一部分，它包括一個類可見性檢查。它將預期類型的??ClassLoader與傳入的類型進行比較。比較方法如下：如果兩個ClassLoader相同，則根據定義，這兩種類型是完全兼容的。如果一個ClassLoader是另一個ClassLoader的父級加載器，則它將認為這兩個類是通過常規ClassLoader層次結構加載的，因此將它們視為相等是安全的。在第二項檢查中，SecurityExplorations發現對漏洞利用的細微修改可能繼續有效。首先，用于偽造類的自定義ClassLoader將目標ClassLoader設置為其父類加載器。可以通過API將其設置為參數：URLClassLoaderlookup_CL = URLClassLoader.newInstance（urlArray，member_CL）。 ClassLoader作為層次結構的一部分，來源：SecurityExplorations。然后，假定ClassLoader的默認行為是將加載類的任務委派給其父加載器，則攻擊者需要確保不能將父ClassLoader加載到此類中，以便其自定義ClassLoader可以工作。借助于Java的通過網絡方法加載類的方法，這種攻擊模式已得到證明：如果此類是通過URL位置定義的，則父ClassLoader將嘗試連接到相關服務器并獲取此代碼。類。此時，預建的HTTP服務器可能會返回404NOTFOUND錯誤，因此父ClassLoader無法加載該類，因此它將控制權轉移到自定義ClassLoader。通過自定義HTTP服務器，在類加載失敗后，強制父ClassLoader加載代碼流，來源：SecurityExplorations。當此漏洞在2016年3月再次出現時，當時的較新版本為8u74，事實證明它很容易受到攻擊，Oracle在8u77中提供了針對此漏洞的修復程序。但是，在8u77發行說明中，此漏洞仍被描述為“ ldquo”，它將影響桌面設備，并且在Web瀏覽器中運行的JavaSE [并且]不會影響Java部署環境，例如典型的服務器或獨立部署的桌面。應用程序，但事實證明它仍然會影響服務器配置和GoogleAppEngine的Java環境。修復：2016年4月29日，本文錯誤地認為此漏洞在8u77、8u91和8u92版本中仍然存在。實際上，它已在8u77中修復。在8u77發行說明中將其描述為對CVE-2016-0636的更正。專門的描述是這樣一種“未知”漏洞，它是在Hotspot子組件中借助未知感染的幫助，并且不包含本文的內容。提到的對CVE-2013-5838的明確引用。但是，SecurityExplorations指出CVE-2016-0636是Issue69的CVE號，而Issue69是他們引用早期CVE-2013-5838的一種方式。 （在本文英文原文的評論區域中，討論了解決此問題的相關過程，有興趣的讀者可以訪問原文進行查看。 Mdash，mdash，譯者注）