第 7 章 已知问题

可以修改 Velocity 模板的攻击者可以执行任意 Java 代码，或者运行具有与运行 Servlet 容器的帐户相同的权限的任意系统命令。这适用于允许不受信任的用户上传/修改 velocity 模板的应用程序，运行 Apache Velocity Engine 版本最多为 2.2。

Fuse 7.9（及更高版本）已修改它的依赖项，以确保它只使用对这个安全漏洞进行保护的 Velocity 版本（即 2.3）。如果您的应用程序代码对 Apache Velocity 组件有任何明确的依赖关系，我们建议升级这些依赖项以使用修复的版本。

Google Guava 版本 11.0 到 24.1，它们容易受到 AtomicDoubleArray 类中的无限内存分配的影响（当使用 Java 序列化序列化）和 CompoundOrdering 类（使用 GWT 序列化处理时）。攻击者可以利用使用 Guava 和 deserialize 不信任的数据的应用程序，从而导致拒绝 service attack- the the more details 部分，请参阅 CVE-2018-10237。

要避免此安全漏洞，我们建议您：

为了更便于避免早期（专用）版本 Guava，Fuse 7.7（及更高版本）已将 Maven Bill of Materials(BOM)文件配置为默认选择 Guava 27。这意味着，如果您将 Fuse BOM 合并到 Maven 项目中（通过将 BOM 的依赖项添加到 POM 文件的 dependency 部分），然后在不指定显式版本 的情况下 对 Guava 工件指定依赖项，则 Guava 版本将默认为 BOM 中指定的版本，这是 Fuse 7.7 BOM 版本的版本。

但是，至少有一种常见用例涉及 Apache Karaf(OSGi)容器，因此无法避免使用存在安全漏洞的 Guava 版本：如果您的 OSGi 应用程序使用 Guava 和 Swagger 一起，则您仍然使用 Guava 20，因为这是 Swagger 所需要的版本。在这里，我们解释了为什么是这种情况以及如何配置 POM 文件以恢复之前（可用）Gusava 20 库。首先，您需要了解 双 OSGi 链 的概念。

双 OSGi 链

OSGi 运行时中的捆绑包使用软件包约束（软件包名称 + 可选版本/range）和导出来连接。每个捆绑包都可以有多个导入，通常这些导入会将给定捆绑包与多个捆绑包相连接。例如：

BundleA
+-- BundleB
|   +-- BundleCa
+-- BundleCb

其中 BundleA 依赖于 BundleB 和 BundleCb，而 BundleB 则依赖 BundleCa。 BundleC a 和 BundleCb 应该是相同的捆绑包，如果导出了相同的软件包，但由于版本（范围）限制，BundleB 使用（有线到）不同的修订版本/版本与 BundleA 不同。

重新编写上图以反映应用程序里的 Guava 和 Swagger 依赖关系时会发生什么：

org.jboss.qe.cxf.rs.swagger-deployment
+-- Guava 27
+-- Swagger 1.5
    +-- reflections 0.9.11
        +-- Guava 20

如果您尝试部署此捆绑包配置，您会看到错误，即 org.osgi.framework.BundleException: Uses constraint violation。

恢复到 Guava 20

如果您的项目同时使用 Guava 和 Swagger 库（直接或间接地），您应该将 maven-bundle-plugin 配置为使用显式版本范围（或没有范围）用于 Guava 捆绑包导入，如下所示：

<Import-Package>
    com.google.common.base;version="[20.0,21.0)",
    com.google.common.collect;version="[20.0,21.0)",
    com.google.common.io;version="[20.0,21.0)"
</Import-Package>

此配置会强制您的 OSGi 应用程序恢复到(vulnerable)Guava 20 库。因此，在这种情况下，避免反序列化 AtomicDoubleArray 实例非常重要。

Apache Solr 是一个流行的开源搜索平台，它使用 Apache Lucene 搜索引擎。如果您的应用程序将 Apache Solr 与 Apache Lucene 结合使用（例如，在使用 Camel Solr 组件时），这会受到此安全漏洞的影响。有关此漏洞的详情，请参阅链接的安全公告以及相关的缓解方案步骤。

Apache Mina SSHD 的 sshd-core 中的一个漏洞允许攻击者溢出服务器导致 OutOfMemory 错误。此问题会影响 Apache Mina SSHD 版本 2.0.0 及更新版本的 SFTP 和端口转发功能。它已在 Apache Mina SSHD 2.7.0 中解决

Apache Mina SSHD 中的这个安全漏洞已被 SSHD-1004 解决，它弃用了具有此漏洞的某些加密算法。在 JBoss EAP 上的 Fuse 7.10 和 Fuse 7.10 中，仍然支持这些已弃用的算法（出于向后兼容的原因）。但是，如果您使用这些已弃用的算法之一，强烈建议您重构应用程序代码以使用不同的算法。

在 Fuse 7.10 中，默认加密算法已更改，如下所示。

在 Fuse 7.10 中，默认密钥交换算法已更改，如下所示。