使用 EOL 版本 Java 的安全漏洞答案

【问题标题】：Security Vulnerability with using EOL version Java使用 EOL 版本 Java 的安全漏洞
【发布时间】：2011-11-07 01:59:21
【问题描述】：

在我们的内部 Intranet Web 服务器上使用以下 Java 版本是否存在安全漏洞？

java version "1.4.2", gij (GNU libgcj) version 4.1.2 20080704 (Red Hat 4.1.2-51)
I think this version was decommissioned in 2008

我们的 Web 服务器非常过时，我一直在推动升级到现代 Java 应用程序服务器和 Java 1.6，但 IT 和我上面的权力还没有看到需要一个。

但后来我收到一封电子邮件，他们发现 Web 服务器存在安全漏洞（工作中的热门话题）

SunOne 6.1, SP9

而且它的补丁需要升级到更新版本的 Java。几周后，我们不再需要一封说明 SunOne 补丁的后续电子邮件，因为它不适用于我们，因此他们将不再升级 JRE。

好吧，SunOne 漏洞可能不适用于我们，但 Java 1.4.2 必须存在一些漏洞，我可以指出并利用我的新应用程序服务器！ :)

【问题讨论】：

理想情况下，各地的每台服务器都应使用最新的补丁和版本保持最新。应该有一个良好的测试流程，以便在这些更新上线之前检测它们的问题。这在现实中通常是不可能的。如果这是一个“内部 Intranet Web 服务器”，如果它被利用，安全漏洞会有什么影响？公司会丢失数据吗？失去时间？将自己暴露在法律惩罚之下？是否有其他安全层来保护此服务器，例如对谁获得帐户的良好控制、真正的隔离等？
@Freiheit (+1)：除此之外，我还要补充一点：理想情况下，每次更新都会提高安全性和可靠性，保持向后兼容性并且不会引入新的错误。 ;)
@Freiheit。老实说，我觉得我们在内部网络上运行这个版本已经足够安全了。这些应用程序不是关键任务，并且每晚都会备份数据。公司发布了一项我必须遵循的安全编码政策，但 IT 人员会说“啊，无需升级即可安全”。我只是在一个过时的平台上编码感到沮丧，我想要 JSF 2.0！重新编码以消除我的安全编码缺陷是痛苦的。我想通过一些手段来获得一个我已经要求了 5 年的现代平台。
好消息@jeff。您可能想在programmers.stackexchange 上搜索。那里有很多关于如何销售版本更改以使您的编码人员做得更好更快的问题。

标签： java security

【解决方案1】：

有两种方法可以说服当权者升级服务器。

表明现有的会导致经济损失。
表明您需要针对所请求的应用程序的新功能。

坦率地说，如果您不直接负责相关服务器的运行状况和维护，那么第一个是一条艰难的道路。有些人可能会认为您提出请求的原因是侵犯了他们的领土，并指出了对黑客的坚实防御的历史。当然，您可能在这方面提出索尼最近的问题.. 后果自负。哎呀，我去过一些地方花了一年多的时间才能在某些 IIS 机器上安装服务包。我什至在一个地方看到了门，在那里我证明了现有的路由器设置意味着我可以轻松获取每个人的电子邮件密码。

从开发人员的角度来看，第二个更容易。最新的 JDK 中是否有您真正需要的东西？例如，某个应用程序的要求只能通过使用新功能来满足？如果没有，那就忘记它。如果有，那么你的经理会为你的东西提供一个新的服务器。

以下是基于纯粹意见的建议。

从 Ethical Coder 的角度来看，如果您有安全问题，请直接与负责人（而不是电子邮件）交谈，然后继续前进。如果您认为安全问题可能会导致健康、财务或其他关键 PII 数据丢失，那么您唯一可以采取进一步措施的时间。此时，您应该向负责人和管理人员发送一封带有适当抄送的电子邮件。但是，一旦完成就放手，因为它完全不在您的掌控之中。这将满足任何警告要求，并且在数据丢失的情况下，您可以确定适当的法律机构将调查该电子邮件跟踪。

我做出区分的原因是，第一条路径允许负责人克服其他人指出他们没有做好自己的工作并决定如何进行。第二个对于在发生严重问题时保护自己很重要。

请记住，常规 IT 有几个问题。首先，该版本的 JDK 当前可以正常工作。基于它的应用程序是功能性的。 IT（一般而言）仅仅因为有可用的更新就被打了太多次升级的东西；由于这个原因，他们可能会反对任何变化。变革和 IT 并不能很好地结合在一起，从更广泛的公司角度来看，这是一件好事。

其次，IT 负责安全。但是，他们有很多工具可供使用。从防火墙到活动监控，再到事件日志传送等。在执行这样的更改之前，他们需要了解新版本的问题（它们始终存在）以及是否还没有解决您的问题引起了人们的注意。换句话说，他们可能已经在 JDK 中解决了这个问题。此外，他们可能已经知道新 JDK 中的问题，但还不能完全解决这些问题……

这让我想到了我的最后一条建议。忽略 JDK 安全问题并专注于您的工作。如果您真的需要新版本，我相信您的经理可以尽一切努力实现它。仅仅为了一个新版本而提倡改变，尤其是这种方式本身是行不通的。

好的，最后一件事：

想象一下，您的开发经理（我们称他为 bob）和 IT 经理正在与他们的老板开一次运营会议。

IT 经理说：“出于安全考虑，jeff 一直在追赶我们升级服务器 x、y 和 z。我们查看了它们，但问题已被我们的防火墙所覆盖。顺便提一下，这些内存错误修复是如何进行的？我们想退役几个箱子。”

Bob：“我们正在努力研究它们。我会通知 jeff。”

他们的老板：（思考）“Bob 似乎无法控制他的团队......他们没有专注于手头的任务，这让我们付出了真金白银。”

现在你在你的老板咒骂名单上。要小心，否则你会被烫伤的。

【讨论】：

另一个“最后一件事”。我刚刚阅读了您的上一个问题（stackoverflow.com/questions/6904117/…）。在我看来，您有升级所需的确切情况，这是比试图说服他们相信安全漏洞更好的途径。这应该会彻底改变想象中的对话。
克里斯，非常感谢您的好评。我觉得如果 IT 需要升级 JRE，他们必须获得一个新的应用服务器，因为我认为 SunOne 与 Java 6 不兼容。除了 VarArgs 之外，我不一定需要更新的 Java 中的东西。
克里斯，在我们公司的内部网络上使用较旧的 Java，我不一定有任何安全问题。我刚刚新的 SunOne 6.1 与 Java6 不兼容，因此我可能会为我的内部实用程序应用程序获得一个更新的应用程序服务器，以帮助其他工程师更轻松地完成工作。
克里斯，您的编辑场景在我的公司，尤其是在我的部门，并非如此。我们不是软件开发公司。我的经理负责签发已签署的完整工程图纸以建造潜艇。我是这个部门的一名工程师，刚刚编写了一个工作流 Java 应用程序，可以帮助同事遵循所需的 6 sigma 程序，这样我们就不会通过审核。所以我的经理和 IT 经理从未见过面 :)

【解决方案2】：

您应该升级。请参阅HTTP Sun Java Calendar Deserialization Priv Escalation，其中描述了多个缓冲区溢出以及影响更新版本的浮点解析 DoS 问题。

与运行 Java 服务器的人相关的是

JRE 以不安全的方式创建临时文件。攻击者可以利用此问题编写任意 JAR 文件并在受影响的计算机上执行受限操作。该问题在 Sun Alert ID 244986 和 CVE-2008-5360 中进行了跟踪。

当 JRE 处理 GIF 图像 (CR 6766136) 和处理字体（CR 6733336 和 6751322）时，会出现多个缓冲区溢出漏洞。这些问题源于 AWT 库中的堆溢出，并且可能允许攻击者执行任意代码。在通过“ConvolveOp”操作进行转换期间将自定义图像模型用于源“光栅”时会出现问题。 Sun Alert ID 244987、CVE-2008-5356、CVE-2008-5357、CVE-2008-5358 和 CVE-2008-5359 中跟踪了这些问题。

存在安全绕过漏洞，因为 JRE 的“Java 更新”机制无法在安装数字签名之前检查它们。这可能允许攻击者通过执行 DNS 欺骗攻击在受影响的计算机上安装恶意文件。该问题在 Sun Alert ID 244989 和 CVE-2008-5355 中进行了跟踪。

JRE 中的一个安全漏洞可能允许不受信任的小程序或应用程序将特权提升到运行恶意应用程序的用户的特权。该问题在反序列化“sun.util.calendar.ZoneInfo”日历对象时出现。攻击者可以通过反序列化日历在特权上下文中反序列化 ZoneInfo 对象。该问题在 Sun Alert ID 244991 和 CVE-2008-5353 中进行了跟踪。

JRE UTF-8（Unicode 转换格式 8）解码器存在一个弱点，因为它接受比“最短”格式更长的编码。攻击者可能会利用此问题来欺骗使用解码器的应用程序接受无效输入。该问题在 Sun 警报 ID 245246 和 CVE-2008-5351 中进行了跟踪。

由于 JRE 不正确地处理 Java 应用程序的远程客户端提供的某些 RSA 公钥，所以会出现拒绝服务漏洞。该问题在 Sun Alert ID 246286 和 CVE-2008-5349 中进行了跟踪。

由于 JRE 通过 Kerberos 对用户进行身份验证的方式，会出现拒绝服务漏洞。攻击者可能会利用这一点耗尽操作系统资源并拒绝为合法用户提供服务。该问题在 Sun Alert ID 246346 和 CVE-2008-5348 中进行了跟踪。

JRE 中的 JAX-WS 和 JAXB 包中的多个安全漏洞可能允许不受信任的小程序以提升的权限执行操作。 Sun Alert ID 246366 和 CVE-2008-5347 中跟踪了这些问题。

由于允许从本地文件系统加载的代码访问本地主机，因此会出现安全绕过漏洞。这可能用于违反同源策略的攻击。 Sun Alert ID 246387 和 CVE-2008-5345 中跟踪了该问题。

【讨论】：

正如斯蒂芬所指出的，这是否与我们安装的 RedHat 版本有关？

【解决方案3】：

任你选：http://www.cvedetails.com/vulnerability-list/vendor_id-5/product_id-1083/version_id-74361/SUN-JDK-1.4.2.html

【讨论】：

java version "1.4.2", gij (GNU libgcj) 不是 SUN JDK
@Stephen，这就是我想知道的。我们的网络服务器是 Sun SunONE。但是 'java --version' 产生 java 版本 "1.4.2" gij (GNU libgcj) 版本 4.1.2 20080704 (Red Hat 4.1.2-51)。感谢您指出这一点。

【解决方案4】：

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java

选择适用于您的特定环境的漏洞

【讨论】：

谢谢，但我如何获得 Java Red Hat 4.1.2-51 的详细信息？我不认为我可以通过电子邮件发送该链接。我做了cve.mitre.org/cgi-bin/cvekey.cgi?keyword=java+Red+Hat+4.1.2-51，但结果仍然模棱两可。