Apache Commons Collections当中的反序列化漏洞可能导致远程代码执行隐患，不过别担心——应对方案已经出炉。
来自Foxglove Security公司的安全研究人员已经证实，第三方Java库当中存在着反序列化漏洞，其可能被用于以远程方式实现JBoss、WebSphere、Jenkins、WebLogic以及OpenNMS的安装等操作。尽管这一问题可能存在于多种应用程序当，但解决该漏洞的关键其实在于开发人员如何处理来自用户的序列化数据——而非第三方库本身。
在存在该漏洞的情况下，应用程序会将序列化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
