安全更新

在这里您可以找到有关 Apache Groovy 发布的安全补丁或更新的信息。请注意,除非另有说明,否则没有可用的二进制或源代码补丁。要获取安全修复程序,您需要升级到 Apache Groovy 的最新维护版本。

2.4.4 之前的版本没有在 Apache 下发布,因此没有可用于旧版本的官方安全更新补丁。

CVE-2015-3253 Apache Groovy 信息泄露

严重程度:重要

供应商:Apache 软件基金会

受影响的版本

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

  • 在 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 的 Zero Day Initiative 合作发现的

参考

CVE-2016-6814 Apache Groovy 信息泄露

严重程度:重要

供应商:Apache 软件基金会

受影响的版本

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

  • 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 与趋势科技的 Zero Day Initiative 合作

历史

  • 2016-09-20 原始公告

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

参考

CVE-2020-17521 Apache Groovy 信息泄露

严重程度:重要

供应商:Apache 软件基金会

受影响的版本

从 2.0 到 2.4.4 的不受支持的 Codehaus 版本的 Groovy。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 版本也是如此,除非在 JDK 7 之前的 JDK 版本上运行,在这种情况下将使用回退实现,该实现现在检查是否成功创建了临时目录。这消除了涉及竞争条件的最高风险情况,即可执行文件或信息可能被修改,但仍然存在敏感信息泄露的可能性。建议 Groovy 2.4/JDK 6 用户使用 java.io.tmpdir 缓解措施。

缓解措施

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

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

鸣谢

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

类似的漏洞

参考

报告问题

Apache 软件基金会积极致力于消除其软件产品中的安全问题。如果您对如何安全地配置或使用 Groovy 有疑问,请发送到用户 邮件列表。如果您发现 Groovy 软件中的错误导致的任何安全问题,请在 错误跟踪器 中提出问题。Apache 软件基金会拥有专门的 安全团队,您可以在需要时联系他们。