Apache Commons Collections當(dāng)中的反序列化漏洞可能導(dǎo)致遠(yuǎn)程代碼執(zhí)行隱患，不過別擔(dān)心——應(yīng)對方案已經(jīng)出爐。

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

[[155771]]

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

在Apache Commons Collections，攻擊者會將來自commons-collections的一個(gè)序列化類作為輸入內(nèi)容，從而利用上述漏洞。此類Commons-collections會經(jīng)過精心設(shè)計(jì)，從而確保在其反序列化流程當(dāng)中執(zhí)行該類中的代碼。

整個(gè)過程非常直觀，不過這并不會妨礙其嚴(yán)重危害?？偠灾?，各位開發(fā)人員造成不要利用來自互聯(lián)網(wǎng)的可執(zhí)行代碼進(jìn)行對象序列化。

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

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

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

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

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

由于Jenkins通過Jenkins CLI界面實(shí)現(xiàn)對象序列化，這就意味著任何人都能夠經(jīng)由該端口利用這一安全漏洞。作為Jenkins的主要贊助方之一，CloudBees剛剛發(fā)布了一套Groovy腳本形式的解決方案，旨在對運(yùn)行在服務(wù)器之內(nèi)的Jenkins CLI子系統(tǒng)進(jìn)行禁用或者移除。

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

Apache Commons團(tuán)隊(duì)在其3.2.X分支版本當(dāng)中發(fā)布了補(bǔ)丁，其在默認(rèn)情況下會在存在漏洞的InvokerTransformer類當(dāng)中以標(biāo)記形式禁用序列化。而該庫的新版本還將在檢測到有用戶試圖對InvokerTransformer進(jìn)行序列化時(shí)發(fā)出異常警告。

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

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

peen則對此做出了辯護(hù)，表示該團(tuán)隊(duì)不可能了解到所有已遭到該庫安全漏洞影響的用戶群體。而Foxglove安全團(tuán)隊(duì)的另一位成員則強(qiáng)調(diào)稱，該安全漏洞并不屬于零日漏洞。但后者的說法似乎并不客觀，因?yàn)閜een特別提到該漏洞給實(shí)際產(chǎn)品造成的威脅目前尚未得到修復(fù)。

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

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

原文標(biāo)題：Lipary misuse exposes leading Java platforms to attack