安全更新

您可以在此处找到有关 Apache Groovy 已发布安全补丁或更新的信息。请注意，除非另有说明，否则不提供二进制或源代码补丁。要获得安全修复，您需要升级到最新维护的 Apache Groovy 版本。

2.4.4 之前的版本不是在 Apache 下发布的，因此旧版本没有官方的安全更新补丁。

CVE-2015-3253 Apache Groovy 信息泄露

严重性：重要

供应商：Apache 软件基金会

受影响版本

  • Groovy 的 Codehaus 不支持版本从 1.7.0 到 2.4.3

  • 在 2.4.4 版本中修复

影响

远程执行不可信代码，DoS

描述

当应用程序的类路径中包含 Groovy 并使用标准 Java 序列化机制在服务器之间通信或存储本地数据时，攻击者可以创建一个特殊的序列化对象，该对象在反序列化时将直接执行代码。所有依赖序列化且不隔离反序列化对象的代码的应用程序都容易受到此漏洞的影响。

缓解措施

Apache Groovy 2.4.4 是 Apache 软件基金会支持的第一个版本。强烈建议所有使用序列化的用户升级到此版本。如果您无法升级或依赖较旧、不支持的 Groovy 版本，您可以在 MethodClosure 类上应用以下补丁 (src/main/org/codehaus/groovy/runtime/MethodClosure.java)

 public class MethodClosure extends Closure {
+    private Object readResolve() {
+        throw new UnsupportedOperationException();
+    }

或者，您应该确保使用自定义安全策略文件（使用标准 Java 安全管理器）或确保您不依赖序列化进行远程通信。

鸣谢

此漏洞由

  • cpnrodzc7 与 HP 的零日计划合作发现

参考

CVE-2016-6814 Apache Groovy 信息泄露

严重性：重要

供应商：Apache 软件基金会

受影响版本

  • Groovy 的 Codehaus 不支持版本从 1.7.0 到 2.4.3

  • Apache Groovy 2.4.4 到 2.4.7

  • 在 2.4.8 版本中修复

影响

远程执行不可信代码，DoS

描述

当类路径中包含 Groovy 的应用程序使用标准 Java 序列化机制（例如，在服务器之间通信或存储本地数据）时，攻击者可以创建一个特殊的序列化对象，该对象在反序列化时将直接执行代码。所有依赖序列化且不隔离反序列化对象的代码的应用程序都容易受到此漏洞的影响。这与 CVE-2015-3253 类似，但此漏洞利用涉及额外的对象包装和异常捕获，现在已对此进行安全防护。

缓解措施

使用受影响版本的 Groovy 用户应采取以下缓解措施之一

  • 隔离进行（反）序列化的代码

  • 升级到 Apache Groovy 2.4.8 或更高版本

  • 旧版 Groovy 用户可以将以下补丁应用于 MethodClosure 类 (src/main/org/codehaus/groovy/runtime/MethodClosure.java)

public class MethodClosure extends Closure {
+    private void readObject(java.io.ObjectInputStream stream) throws
IOException, ClassNotFoundException {
+        if (ALLOW_RESOLVE) {
+            stream.defaultReadObject();
+        }
+        throw new UnsupportedOperationException();
+    }

鸣谢

此漏洞由

  • Pentest Limited 的 Sam Thomas 与 Trend Micro 的零日计划合作

历史

  • 2016-09-20 原始建议

  • 2017-01-12 更新了受影响版本的信息

参考

CVE-2020-17521 Apache Groovy 信息泄露

严重性：重要

供应商：Apache 软件基金会

受影响版本

Groovy 的 Codehaus 不支持版本从 2.0 到 2.4.4。Apache Groovy 版本 2.4.4 到 2.4.20、2.5.0 到 2.5.13、3.0.0 到 3.0.6 和 4.0.0-alpha-1。

在 2.4.21、2.5.14、3.0.7、4.0.0-alpha-2 版本中修复

影响

此漏洞可能影响类 Unix 系统以及非常旧的 Mac OSX 和 Windows 版本。在这些操作系统版本上，Groovy 可能会在操作系统临时目录中创建临时目录，该目录在受影响系统上的所有用户之间共享。Groovy 会在生成 Java 存根（影响非常低）时内部使用此类目录，或者通过两个扩展方法 [4,5] 代表用户代码创建临时目录。如果 Groovy 用户代码使用这些扩展方法中的任何一个，并将可执行代码存储在生成的临时目录中，则风险很高，因为这可能导致本地权限提升。如果此类 Groovy 代码使用临时目录存储敏感信息，则风险中等，因为此类信息可能会被泄露或修改。

在分析此漏洞的影响时，以下是需要问的重要问题

Groovy 代码是否在受影响的操作系统上运行？其他用户是否可以访问运行 Groovy 代码的机器？Groovy 代码是否使用 Groovy 的 createTempDir 扩展方法 [4,5] 创建临时目录？

如果您对这些问题中的任何一个回答“否”，则不受影响。如果您回答“是”，Groovy 代码是否在临时目录中写入或存储可执行代码？如果您回答“是”，则风险很高，可能导致本地权限提升。Groovy 代码是否将敏感信息（如 API 密钥或密码）写入临时目录？如果您回答“是”，则风险中等，信息可能会被泄露或修改。

描述

Groovy 正在使用 JDK 中的一个方法，该方法现在被标记为不适用于安全敏感上下文。此外，Groovy 没有检查与成功创建临时目录相关的标志，这导致了存在漏洞的竞争条件 [1]。

对于已修复的版本，Groovy 2.5 及更高版本现在使用较新的 JDK 方法，该方法创建的目录仅由运行 Groovy 代码的用户可读。已修复的 Groovy 2.4 版本也如此，除非在 JDK7 之前的 JDK 版本上运行，在这种情况下使用回退实现，该实现现在检查临时目录是否成功创建。这消除了涉及竞争条件的高风险场景，在该场景中可执行文件或信息可能被修改，但仍然存在敏感信息泄露的可能性。建议 Groovy 2.4/JDK 6 用户使用 java.io.tmpdir 缓解措施。

缓解措施

将 java.io.tmpdir 系统环境变量设置为执行用户独有的目录将修复所有操作系统和所有 Groovy 版本的此漏洞。

无法轻松迁移到已修复的 Groovy 版本的用户可能希望考虑使用 JDK 的 Files#createTempDirectory 方法而不是 Groovy 扩展方法。

鸣谢

此漏洞由 Jonathan Leitschuh (https://twitter.com/jlleitschuh) 发现

类似漏洞

参考

[1] CWE-379：在权限不安全的目录中创建临时文件 (https://cwe.mitre.org/data/definitions/379.html) [2] 不应使用“File.createTempFile”创建目录 (https://rules.sonarsource.com/java/RSPEC-5445/) [3] Groovy CVE 列表 (https://groovy-lang.cn/security.html) [4] https://docs.groovy-lang.cn/latest/html/groovy-jdk/java/io/File.html#createTempDir() [5] https://docs.groovy-lang.cn/latest/html/groovy-jdk/java/io/File.html#createTempDir(java.lang.String,%20java.lang.String) [6] 相关 Jira 问题：https://issues.apache.org/jira/browse/GROOVY-9824

报告问题

Apache 软件基金会在消除其软件产品中的安全问题方面采取了非常积极的立场。如果您对如何安全配置或使用 Groovy 有疑问，应将其发送到用户邮件列表。如果您发现由于 Groovy 软件中的错误而导致的任何安全问题，应在错误跟踪器中提出问题。Apache 软件基金会有一个专门的安全团队，您可以在需要时联系他们。