CVE-2015-4852：评估应用程序的漏洞答案

【问题标题】：CVE-2015-4852: Evaluating Apps for VunerabilityCVE-2015-4852：评估应用程序的漏洞
【发布时间】：2015-11-13 04:52:14
【问题描述】：

我从 CVE-2015-4852 by Foxglove 的文章和示例漏洞的理解是，您需要接收用户提供的序列化对象的代码和类路径中存在的 Apache 公共集合来利用。

有了这两件事，一个请求应该是可以处理的（尽管有些可能需要反复试验/系统知识）。

作为I commented in this question about Spring Vulnerabilities，对于易受攻击的产品，它不必直接使用InvokerTransfomer。有问题的对象由漏洞利用请求提供。 “易受攻击的应用程序”所要做的就是提供 commons-collections JAR 和在用户提供的 InvokerTransformer 实例上调用 .readObject() 的逻辑。

假设我正确理解这一点......是否足以根据从调用 ObjectInputStream.readObject() 方法的位置向后追溯来评估产品（您有来源）并得出结论，如果存在产品很可能容易受到攻击流可以包含外部用户提供的对象的任何方式？

【问题讨论】：

我真的希望 VeraCode 和其他静态分析工具将其添加到他们的污点分析中。即使使用数据流分析工具手动执行此分析也非常棘手且耗时。

标签： java security deserialization exploit

【解决方案1】：

是的，如果不可信数据有路径可以调用 ObjectStream.readObject() 并且 InvokerTransformer 在类路径上，则产品或库很容易受到攻击.

如果您必须接受用于反序列化的不受信任的数据，那么您可以阻止包含 InvokerTransformer 的负载。您必须推出自己的可序列化格式解析器或找到可以做到这一点的安全库。

另一种缓解方法是在一个单独的类加载器中反序列化，而 InvokerTransformer 无法访问该类加载器。

远更好 - 正如@PhaedrusPhacdelm 发现的那样 - 将允许的反序列化类列入白名单： http://fishbowl.pastiche.org/2015/11/09/java_serialization_bug/ http://www.ibm.com/developerworks/library/se-lookahead/

【讨论】：

打地鼠游戏就这样开始了。工作直到找到像 InvokerTransformer 这样的下一个类...
从开发的角度来看，这是一个很好的总结：fishbowl.pastiche.org/2015/11/09/java_serialization_bug 链接到ibm.com/developerworks/library/se-lookahead .... 显示处理此问题的理想方法不是阻止特定类，而是仅将其列入白名单您愿意通过自定义对象流上的resolveClass() 接受的类。
向查尔斯·米勒 (stackoverflow.com/users/3052/charles-miller) 推荐以上博文中的提示。
InvokerTransformer 只是一种利用不可信数据反序列化的方法。即使没有可用的 InvokerTransformer，也可能存在其他可以恶意利用副作用的类。
即使我们在序列化/反序列化过程中不使用自定义 java 对象，应用程序是否也会受到影响。例如：如果我的应用程序只是从流中反序列化字符串或其他标准 java 对象（整数），我是否仍会因此漏洞而受到影响（假设 InvokerTransformer 在类路径中）？