第 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 类（当使用 research 序列化序列化）中无限的内存分配。攻击者可以利用使用 Guava 和反序列化不序列化数据的应用程序，从而导致拒绝 service iwl-osgi。如需更多信息，请参阅 CVE-2018-10237。

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

为了便于避免较早版本的 Guava，Fuse 7.7 （及更高版本）版本已经为所有容器配置了 Maven Bill of Materials (BOM)文件，以默认选择 Guava 27。这意味着，如果您在 Maven 项目中将 Fuse BOM 整合到 Maven 项目中（通过将 BOM 的依赖添加到 POM 文件的 dependencyManagement 部分），然后在没有指定显式版本 的情况下 指定 Guava 工件的依赖关系，Genava 版本将默认为 BOM 中指定的版本，即 Fuse 7.7 BOM 的版本 27。

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

双 OSGi 链

OSGi 运行时中的捆绑包使用软件包约束（软件包名称 + 可选版本/范围）来连接 together，以及 exports。每个捆绑包可以有多个导入，通常那些导入一个带有多个捆绑包的捆绑包。例如：

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

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

重写前面的图，以反映应用程序中的 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) Garava 20 库。因此，在这种情况下，务必要避免反序列化 AtomicDoubleArray 实例。

Apache Solr 是一个流行的开源搜索平台，它使用 Apache Lucene 搜索引擎。如果您的应用程序使用 Apache Solr 与 Apache Lucene （例如，使用 Camel Solr 组件）的 Apache 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 中，默认的密钥交换算法已更改，如下所示：