Apache Commons Collections當中的反序列化漏洞可能導致遠程代碼執行隱患，不過別擔心——應對方案已經出爐。

來自Foxglove Security公司的安全研究人員已經證實，第三方Java庫當中存在著反序列化漏洞，其可能被用于以遠程方式實現JBoss、WebSphere、Jenkins、WebLogic以及OpenNMS的安裝等操作。盡管這一問題可能存在于多種應用程序當，但解決該漏洞的關鍵其實在于開發人員如何處理來自用戶的序列化數據——而非第三方庫本身。

[[155771]]

在存在該漏洞的情況下，應用程序會將序列化Java對象作為輸入內容加以接收。而一旦開發人員決定接收這些作為用戶輸入內容存在序列化數據——也就是被轉化為另一種格式的應用程序數據，反序列化漏洞即擁有了作惡的機會，其會嘗試對數據進行回讀。

在Apache Commons Collections，攻擊者會將來自commons-collections的一個序列化類作為輸入內容，從而利用上述漏洞。此類Commons-collections會經過精心設計，從而確保在其反序列化流程當中執行該類中的代碼。

整個過程非常直觀，不過這并不會妨礙其嚴重危害。總而言之，各位開發人員造成不要利用來自互聯網的可執行代碼進行對象序列化。

Foxglove Security公司的Steve peen在一份詳盡的博文當中指出，目前受到該漏洞影響的絕不僅僅是商用應用程序。各類利用存在該漏洞的第三方庫版本的定制化Java應用程序同樣位列潛在受害者名單，其中包括Apache Commons Collections、Groovy乃至Spring等等。Foxglove技術團隊還在GitHub上發布了一個概念驗證項目，其利用的正是今年1月曝出的Apache Commons反序列化遠程代碼執行漏洞。

Foxglove方面演示了向AdminService發送一條SOAP請求以實現針對WebSphere的攻擊活動，并通過類似的方式向JMXInvoker服務發送請求以完成攻擊。任何利用javax.management端口進行遠程對象序列化且存在該安全漏洞的庫都成為潛在的安全威脅。而任何運行有RMI的服務器亦面臨著同樣的安全風險——不過如果RMI端口向互聯網開放，那么該服務器遭遇安全問題的機率還會進一步提升。

不過大家先別急著對Java應用程序有可能受到遠程代碼執行漏洞影響而感到恐慌——需要指出的是，盡管該問題確實相當嚴重而且廣泛存在，不過博文強調目前還沒有任何圍繞其出現的重大安全事故。peen將該問題描述為“2015年最不受重視且知名度最低的安全漏洞。”而且事實上Java甚至是Apache Commons Collections本身都沒有任何問題，真正導致安全隱患的是那些第三方庫。

有鑒于此，開發人員應當保證應用程序拒絕任何作為輸入內容的序列化對象。如果應用程序必須接收序列化對象，那么用戶輸入內容應當首先接受掃描以確認其安全性。

“如果應用程序不具備面向來自非受信用戶輸入內容的反序列化類白名單，那么由此引發的安全后果只能說是自作自受，”一位昵稱為artpistol的用戶在Slashdot上寫道。

由于Jenkins通過Jenkins CLI界面實現對象序列化，這就意味著任何人都能夠經由該端口利用這一安全漏洞。作為Jenkins的主要贊助方之一，CloudBees剛剛發布了一套Groovy腳本形式的解決方案，旨在對運行在服務器之內的Jenkins CLI子系統進行禁用或者移除。

事實上，博文當中提到的對應用程序輸入內容進行全面掃描的說法確實讓人有些擔憂，不過目前各類修復機制已經正式發布正在籌備當中。WebSphere Application Server早在今年4月就已經修復了該問題。而今年早些時候，Groovy已經在由Apache基金會發布的2.4.4版本當中解決了該問題。其建議用戶從Apache處將Groovy升級至最新版本，從而規避上述安全問題。Jenkins方面亦承諾在本周三之前完成相關修復工作。

Apache Commons團隊在其3.2.X分支版本當中發布了補丁，其在默認情況下會在存在漏洞的InvokerTransformer類當中以標記形式禁用序列化。而該庫的新版本還將在檢測到有用戶試圖對InvokerTransformer進行序列化時發出異常警告。

OpenNMS用戶可以直接對該服務器的防火墻進行配置以禁用指向端口1099的遠程訪問，從而屏蔽相關攻擊向量，該開發團隊在一篇博文當中指出。而在理想的設置狀態下，用戶應當將iptables等運行在OpenNMS服務器之上并將遠程訪問限定在最低數量的端口組之內，例如由端口22用于ssl、端口162用于SNMP陷阱處理。該應用程序需要訪問來自localhost的其它端口，但其只面向那些已經對該服務器進行過shell訪問的對象。

OpenNMS顧問Jeff Gehlbach在一條推文當中指出，OpenNMS擁有一個專門用于報告安全問題的電子郵箱地址，而Foxglove研究人員們卻沒有利用它提前對該團隊發出提醒。事實上，在將這一安全隱患以零日漏洞的形式在博文中發布之前，相關應用程序從未受到過任何影響。

peen則對此做出了辯護，表示該團隊不可能了解到所有已遭到該庫安全漏洞影響的用戶群體。而Foxglove安全團隊的另一位成員則強調稱，該安全漏洞并不屬于零日漏洞。但后者的說法似乎并不客觀，因為peen特別提到該漏洞給實際產品造成的威脅目前尚未得到修復。

“那些擁有漏洞修復支持SLA的客戶會將其視為零日漏洞，無論這種看法正確與否，”Gehlbach表示。盡管阻斷訪問端口能夠有效防止OpenNMS之上出現任何相關問題，但該團隊仍然在認真考慮如何從代碼修改的角度出發實現更為可行的保護效果。

開發人員應當在修復版本正式推出之后確保對受影響的庫進行更新。另外，他們還應當采取進一步舉措來妥善解決序列化對象在Java應用程序當中的作用與處理方式。

原文標題：Lipary misuse exposes leading Java platforms to attack