基于Java漏洞的安全策略探析

◆鄭 艷

?

基于Java漏洞的安全策略探析

◆鄭 艷

(無錫城市職業技術學院 江蘇 214000)

互聯網技術的快速發展引發了人們對于網絡安全的廣泛關注。特別是近期發生的安全事例表明，面向Java的攻擊已經成為網絡系統安全的潛在主因。本文從Java平臺的安全體系出發，結合實際的案例分析漏洞原因，從多個層面提出了Java應用服務管理的安全應對策略。

Java平臺；安全漏洞；網絡安全；安全策略

0 引言

Java是一種廣泛地運用于網絡數據的共享和分布處理的軟件技術，安裝在各種不同類型的設備上，包括大多數PC機、蘋果電腦和Linux臺式機，以及智能手機和其他嵌入式設備。最近幾年發布的卡巴斯基安全公告顯示：Oracle Java已經成為最常被網絡罪犯進行漏洞攻擊的軟件，針對Java安全漏洞的襲擊數量一直在穩步上升，造成的感染占所有相關攻擊的50%左右[1]。網絡技術具有被惡意程序攻擊的特殊性，Java成為最易受到攻擊的軟件之一，因此針對Java漏洞進行攻擊的安全問題急需大家思考面對[2]。

Java的安全存在以下幾個主要因素：

（1）由于Java開源，黑客容易發現不安全代碼，這使得一些不安全的編碼成為攻擊的重點；

（2）Java的跨平臺特性，使得Java在出現漏洞后，很多不同的系統平臺上易受到漏洞的影響很大；

（3）Java的安全團隊建設落后，它的安全補丁更新相對緩慢，且版本更新通常落后于安全修補過程；

（4）Java的新版本和舊版本之間存在一些兼容性問題，使得很多企業不愿意升級到新版本的Java上。正是存在這些原因，Java面臨的安全形勢總體上不容樂觀。

本文在第二部分首先介紹Java技術上目前的安全體系；在第三部分通過一些實際的漏洞案例，分析漏洞出現的可能原因；最后本文提出Java在程序設計和管理等方面的安全應對思路。

1 Java安全體系

圖1 Java安全體系結構

Java既是一種安全性的編程語言，也是一種需要安裝從而支持Java程序運行的軟件，它具有額外的保護，比如說沙箱(sandboxes)和額外的內存保護，這是其他編程語言沒有的。Java平臺提供了Java安全的基本功能[3]，它在初始化和運行時兩方面提供安全管理，以全局集中、節點自治的協同方式保證安全。安全管理器定義沙箱的邊界，保護虛擬機的外部資源。

Java安全策略包含以下基本組件：Java內置的語言安全特性、字節碼校驗器、類加載器、安全管理器，結構如圖1所示。安全體系的各組件相互配合、相互保護，共同形成Java的基本安全防御體系。

1.1 語言安全特性

Java語言的安全特性主要來源于對直接內存操作的約束。Java在使用對象時，嚴格遵守類型規則：只有相同類型的對象，才能進行轉換；另外它還通過在字節碼指令中去除非結構化的內存訪問指令，保證了Java 程序只能使用類型安全的、結構化的方法去訪問內存；Java虛擬機的內存布局也與具體平臺相關，這增強了內存訪問限制的難度。另外，通過自動垃圾收集機制，開發人員無需在內存沖突的問題上糾纏不清，不必為顯式釋放內存而擔心。這種機制降低了程序出錯的可能性，提高了編程的效率。

通過在每次操作數組時，檢查數組的邊界，Java避免了潛在的內存沖突；通過對對象引用的檢查，Java確保這些引用不為空值；通過在編譯階段檢查未被初始化的局部變量，Java避免了容易出問題的編程陷阱。利用這些語言級的安全特性，不僅使得Java程序更為健壯，也使得Java虛擬機的運行更為安全。

1.2 字節碼校驗器

字節碼校驗器主要是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。校驗包括文件格式驗證、元數據驗證、字節碼驗證和符號引用驗證。

文件格式驗證主要驗證字節流是否符合Class文件格式的規范，并且能被當前的虛擬機處理，判斷是否以魔數開頭、版本號是否在當前虛擬機處理范圍之內、尾部是否附帶其他的字節等。虛擬機將依據字節流在方法區建立相應的存儲結構；類數據的語義驗證主要對上一步在方法區中建立的類的元數據進行語義分析，以保證其符合Java語言規范的要求，判斷這個類是否有父類、是否繼承了final類、是否實現了其父類中的抽象方法、類中的字段、方法是否和父類產生矛盾等等；字節碼驗證主要針對類數據中的方法進行數據流和控制流分析，判斷跳轉指令是否跳轉到方法體以外的字節碼指令上、類型轉換是否有效、操作數棧是否總是包含正確的數值以及正確的類型、局部變量訪問之前是否被初始化等等；符號引用驗證為動態鏈接的一部分，虛擬機將追蹤那些引用——從被驗證的class文件到被引用的class文件，此次驗證可能涉及到裝載新的類，然后將在編譯時的符號連接轉換為直接引用—指向類、字段或方法的指針或偏移量。

1.3 類加載器

類加載器是將字節碼文件加載進內存，并最終形成可被虛擬機使用的Java類型。虛擬機的類加載器可以分為引導類加載器、擴展類加載器、系統類加載器、網絡類加載器和其它自定義類加載器。如圖2所示，引導類加載器負責加載系統類（在rt.jar中），擴展類加載器加載位于jre/lib/ext目錄下的各個類，系統類加載器用于加載位于CLASSPATH環境變量所指定目錄下的類，網絡類加載器和其它自定義類加載器負責加載網絡上的或者用戶指定的類。

圖2 類加載器結構

虛擬機的類加載采用的是“雙親委派加載機制”。除去引導類加載器外的每一個類加載器，都有一個“雙親類”加載器。在某個特定的類加載器試圖加載class之前，它會先默認地將此任務“委派”給其雙親，委派的過程一直向上，直至到達引導類加載器。引導類加載器一般是委派鏈中的最后一個類加載器。類加載器的雙親類如果有能力來加載這個類，則這個類加載器返回這個類型；否則類加載器自身試圖來加載這個類型。通過這種“委派”機制，類加載器可以保證可信任類的加載先于不可信類，并讓不可信類由另外的類加載器加載，從而形成不同的運行時包，進而保護可信類的包訪問權限，剔除裝著被信任的不可靠類，達到保護可信任類庫邊界的目的。

1.4 安全管理器

Java虛擬機中的安全管理器基于策略文件來管理權限。如圖3，安全策略建立了代碼來源和訪問權限集之間的映射關系。代碼來源由代碼位置和證書組成，代碼位置指明了類的來源，證書用來保證代碼沒有被篡改。權限是用戶允許程序的操作，由權限類型、權限名和一組權限操作組成。其類型主要有文件權限、套接字權限、屬性權限、運行時權限等權限。在初始化時，虛擬機根據安全策略，初始化相應的權限集合，并將代碼來源和權限集合放置到一個指定的保護域的對象中，當安全管理器在檢查某一權限時，它查看當前位于調用堆棧上的所有方法的類，獲取相應的類保護域，并詢問每個保護域，確認此操作是否能被保護域所允許。如果某一層保護域的因素發生不同意此操作，虛擬機就會引起安全保護異常而退出。根據應用的不同特點，可以對安全管理器進行配置，以滿足應用的不同安全需求。準確、有效地配置安全策略是一項復雜的任務，并可能導致錯誤。在實現安全管理時，任何錯誤都將變成運行時的安全漏洞。

圖3 安全管理器

在虛擬機初始化階段，虛擬機根據安全策略文件初始化在開始階段就確定訪問控制集，當運行時如果應用調用可能危害系統安全的系統調用時，比如建立套接字連接、修改系統屬性等等操作，此時核心API首先和安全管理器交互，確認此行為是否允許。只有通過授權的行為才能繼續執行，否則安全管理器將因安全管理異常退出。

2 漏洞案例

結合具體的漏洞案例，本節分別從應用層框架、核心類庫以及虛擬機本身這幾個角度去分析一下Java漏洞的成因。

2.1 應用框架層漏洞

漏洞存在于web框架struts2中，漏洞ID為CVE-2010-1870 。Struts2是Java程序員廣泛應用的web開發框架，此漏洞允許運程執行用戶代碼。Struts2內部使用WebWork調用XWork所引發。XWork目的在于提供一個泛化的、可重用且可擴展的命令模式框架，其提供了很多核心功能，比如運行時表單檢查、類型轉換、強大的表達式語言OGNL――the Object Graph Navigation Language、IoC――Inversion of Control等功能。XWork在從HTTP的參數中獲取對應action的名稱時不允許名稱擁有’#’字符，防止和內部自定義的變量沖突，但攻擊者通過使用’#’的Unicode編碼u0023替代‘#’，構建出特殊的url，如圖4。

圖4 構建特殊的url

其中，#_memberAccess、#foo、#context、#rt是XWork的內部變量，通過此url可以設置XWork的內部變量#_xwork.MethoAccessor.denyMethodExecution為true，最終使得服務端允許執行java.lang.Runtime.getRuntime().exit(1)方法，從而形成攻擊。

2.2 核心類庫層漏洞

漏洞ID為CVE-2012-4681，就是一個該類的典型漏洞，它影響windows、Linux、OS X平臺。攻擊者使用applet突破沙箱限制，再利用javascript下載惡意軟件到本地機器上執行，從而完成攻擊。利用此漏洞，攻擊者可以獲取對用戶電腦的全部權限，可以在用戶電腦上執行任何操作。此漏洞曾被制成工具，影響數百萬臺電腦。

通過圖5代碼可以看出，漏洞的成因主要是由于核心類的Expression類開放了讀取核心包的權限；同時Sun.awt.SunToolkit類中的方法getField在改變字段的訪問權限時繞過安全檢查；最后，使用反射的技術，將Statement類的私有數據成員acc（類型為AccessControlContext）修改為公有，并設置成擁有完全權限，從而達到突破沙箱的目的。

圖5 漏洞攻擊代碼

2.3 虛擬機層漏洞

漏洞ID為CVE-2010-4476，漏洞類型為拒絕服務，主要會影響web服務提供商。此漏洞的成因主要是出現在虛擬機內部，對雙精度浮點的極值處理不當上，當攻擊者構造一個特殊的url，比如http://www.xxxxx.net/order.do?order.money=2.2250738585072012e-308，此數字應該被轉換為0x1.0p-1022（Double.MIN_NORMAL），但是虛擬機陷入0x1p-1022到0x1.fffffffffffffP-1022之間的循環，即虛擬機陷入死循環，從而形成拒絕服務攻擊。

3 應對策略

通過前面的分析，可知Java漏洞可能存在于應用本身、應用服務及中間件、核心類庫及虛擬機內部等各個方面。本小節就從Java應用安全、應用服務及中間安全、Java虛擬機平臺安全這三個角度分別去探討開發者在Java開發過程中的應對思路。

3.1 應用安全

根據美國國家漏洞數據庫的數據顯示，每年發現的漏洞趨勢有以下特點：每年有數千個漏洞被發現，其中大多數漏洞的危害程度高，而復雜性卻反而較低；這些漏洞多出現于應用程序中，易于被利用的漏洞占了大多數，因此確保應用的安全十分重要。為此，微軟首先提出了安全開發流程SDL（Security Development Lifecycle）。SDL試圖在軟件開發的開始，就將安全性融入到軟件開發的整個生命周期，從安全漏洞的源頭上解決問題，以保證產品的安全性。

3.2 應用服務及中間件安全

通過使用應用服務和中間件，可以大幅降低軟件開發成本，提高開發效率，但一旦其出現安全漏洞，影響應用的范圍也很大。故而，應用服務及中間件的安全很重要。在應用服務及中間件這一層，解決某些問題很有效，比如通過使用模版引擎可以有效解決XSS攻擊、通過使用標記可以解決CSRF攻擊。在這一層中，統一解決此類問題，不僅可以有效防止“遺漏”的問題，而且有利于制定一致的安全方案，統一安全標準。最后，保證應用服務及中間件的安全，還需要建立積極地應對策略，保證其組件能夠打上最新的安全補丁。

3.3 Java平臺安全

為了增強Java平臺安全，可以調整Java的訪問控制模型。文獻[4-6]探討并修改了訪問控制模型，動態形成訪問控制權限的可能性；文獻[7]分析了在分布式環境下安全模型的適應性；文獻[8]研究了在MOP模型下Java安全性問題。

虛擬機對于本地共享庫的安全防護僅僅局限于是否允許加載，而對其本地庫的行為沒有做任何的驗證。安全管理器可以考慮將本地共享庫也納入到安全管理范疇。最后，虛擬機存在大量的本地代碼（97828行代碼，使用wc程序統計），這部分代碼可能會破壞虛擬機內存中的數據結構，故而需要對這一部分代碼執行檢查。可以事先制定本地安全編碼規則對這部分本地代碼做安全檢查。

4 結束語

Java所面臨的威脅不容低估，它是當前各種網絡攻擊的重點，對于攻擊者而言是很有吸引力的目標。雖然Java本身有一套結構嚴密的安全體系，且Oracle宣布將著重解決Java的安全漏洞問題，但因為Java是開源的，且最新的Java版本更新頻繁（包括安全補丁的更新），Java漏洞的存在總是難以避免。因此那些負有直接責任的Java應用開發人員時時要提高安全意識，在開發過程中創建一個Java的安全框架，使用安全開發流程，管理人員需要在發現漏洞存在的時候盡快更新JDK，增加更新Java的優化措施，以防止系統被黑客利用，減少與Java相關的風險。

[1]卡巴斯基年度安全報告.卡巴斯基實驗室, 2013-2017.

[2]Venners, Bill. Inside the Java 2 Virtual Machine[M]. McGraw-Hill Companies, 2000.

[3]Oaks, Scott. Java Security[M]. O'Reilly Media, 2002.

[4]Liu, Dongxi. Bytecode Verification for Enhanced JVM Access Control[C]. in Availability, Reliability and Security,the Second International Conference, Vienna, 2007.

[5]Autrel, Fabien and Cuppens-Boulahia, Nora and Cuppens, Frederic. Enabling Dynamic Security Policy in the Java Security Manager[C]. in Proceedings of the 5th International Conference on Foundations and Practice of Security, Montreal, QC, Canada, 2013.

[6]Inoue, Hajime. Inferring Java Security Policies Through Dynamic Sandboxing[C]. in In International Conference on Programming Languages and Compilers, Las Vegas, 2005.

[7]Roudier, Refik Molva and Yves. A distributed access control model for Java[C]. in 6th European Symposium on Research in Computer Security, Toulouse, France, 2000.

[8]Vayssière, Denis Caromel and Julien. Reflections on MOPs, components, and Java security[C]. in 15th European Conference Object-Oriented Programming Proceedings, Bugapest, Hungary, 2001.