Chapter 7. Known Issues

An attacker that is able to modify Velocity templates may execute arbitrary Java code or run arbitrary system commands with the same privileges as the account running the Servlet container. This applies to applications that allow untrusted users to upload/modify velocity templates running Apache Velocity Engine versions up to 2.2.

Fuse 7.9 (and later) has modified its dependencies to ensure that it uses only the Velocity version (that is, version 2.3) that has been fixed to protect against this security vulnerability. If your application code has any explicit dependencies on the Apache Velocity component, we recommend that you upgrade these dependencies to use the fixed version.

Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service — for more details, see CVE-2018-10237.

To avoid this security vulnerability, we recommend that you:

To make it easier to avoid the earlier (vulnerable) versions of Guava, Fuse 7.7 (and later) has configured its Maven Bill of Materials (BOM) files for all containers to select Guava 27 by default. This means that if you incorporate a Fuse BOM into your Maven project (by adding a dependency on the BOM to the dependencyManagement section of your POM file) and then specify a dependency on the Guava artifact without specifying an explicit version, the Guava version will default to the version specified in the BOM, which is version 27 for the Fuse 7.7 BOMs.

But there is at least one common use case involving the Apache Karaf (OSGi) container, where it is not possible to avoid using a vulnerable version of Guava: if your OSGi application uses Guava and Swagger together, you are obliged to use Guava 20, because that is the version required by Swagger. Here we explain why this is the case and how to configure your POM file to revert the earlier (vulnerable) Guava 20 library. First, you need to understand the concept of a double OSGi chain.

Double OSGi chain

Bundles in the OSGi runtime are wired together using package constraints (package name + optional version/range) — imports and exports. Each bundle can have multiple imports and usually those imports wire a given bundle with multiple bundles. For example:

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

Where BundleA depends on BundleB and BundleCb, while BundleB depends on BundleCa. BundleCa and BundleCb should be the same bundle, if the export the same packages, but due to version (range) constraints, BundleB uses (wires to) a different revision/version of BundleC than BundleA.

Rewriting the preceding diagram to reflect what happens when you include dependencies on both Guava and Swagger in an application:

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

If you try to deploy this bundle configuration, you get the error, org.osgi.framework.BundleException: Uses constraint violation.

Reverting to Guava 20

If your project uses both Guava and Swagger libraries (directly or indirectly), you should configure the maven-bundle-plugin to use an explicit version range (or no range at all) for the Guava bundle import, as follows:

<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>

This configuration forces your OSGi application to revert to the (vulnerable) Guava 20 library. It is therefore particularly important to avoid deserializing AtomicDoubleArray instances in this case.

Apache Solr is a popular open source search platform that uses the Apache Lucene search engine. If your application uses a combination of Apache Solr with Apache Lucene (for example, when using the Camel Solr component), it could be affected by this security vulnerability. Please consult the linked security advisory for more details of this vulnerability and the mitigation steps to take.

A vulnerability in sshd-core of Apache Mina SSHD allows an attacker to overflow the server causing an OutOfMemory error. This issue affects the SFTP and port forwarding features of Apache Mina SSHD version 2.0.0 and later versions. It was addressed in Apache Mina SSHD 2.7.0

This vulnerability in Apache Mina SSHD was addressed by SSHD-1004, which deprecates certain cryptographic algorithms that have this vulnerability. In Fuse 7.10 on Karaf and Fuse 7.10 on JBoss EAP, these deprecated algorithms are still supported (for reasons of backwards compatibility). However, if you are using one of these deprecated algorithms, it is strongly recommended that you refactor your application code to use a different algorithm instead.

In Fuse 7.10, the default cipher algorithms have changed as follows.

In Fuse 7.10, the default key exchange algorithms have changed as follows.

On OCP 4.9 (or later), the application-monitoring project no longer works. It is a prerequisite for monitoring Fuse Online integrations and infrastructure components with Prometheus and Grafana.

To work around this issue, you can use the built-in monitoring stack (in the openshift-monitoring namespace) to use the openshift-user-workload-monitoring feature and the grafana-operator to use the ops addon as described in the Important notes for Fuse Online section of these release notes.

Maven 3.9.2 does not explicitly pass org.apache.maven.plugin.internal.PlexusUtilsInjector as dependency graph transformer.

See the Maven issue MNG-6965 for more information.

As a workaround, you an add plexus-utils as a patch-maven-plugin dependency:

<build>
    <plugins>
        <plugin>
            <groupId>org.jboss.redhat-fuse</groupId>
            <artifactId>patch-maven-plugin</artifactId>
            <version>${version.redhat.fuse}</version>
            <extensions>true</extensions>
            <dependencies>
                <dependency>
                    <groupId>org.codehaus.plexus</groupId>
                    <artifactId>plexus-utils</artifactId>
                    <version>3.5.1</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

In Fuse 7.10, the API Designer (Apicurito) does not work properly, if it is installed via the Apicurito Operator (giving an Invalid Cert Error). To work around this problem:

While running patch:install in the Apache Karaf container on the Windows platform, under certain circumstances you might encounter the following error when the patch:install command attempts an automatic restart of the container:

Red Hat Fuse starting up. Press Enter to open the shell now...
100% [========================================================================]
Karaf started in 18s. Bundle stats: 235 active, 235 total
'.tmpdir' is not recognized as an internal or external command,
operable program or batch file.
There is a Root instance already running with name ~14 and pid ~13. If you know what you are doing and want to force the run anyway, SET CHECK_ROOT_INSTANCE_RUNNING=false and re run the command.

If you encounter this error, simply restart the Karaf container manually.

Starting in the Fuse 7.0 GA release, in the Apache Karaf container the start level of hot deployed bundles is 80 by default. This can cause problems for the hot deployed bundles, because there are many system bundles and features that have the same start level. To work around this problem and ensure that hot deployed bundles start reliably, edit the etc/org.apache.felix.fileinstall-deploy.cfg file and change the felix.fileinstall.start.level setting as follows:

felix.fileinstall.start.level = 90

The framework-security OSGi feature must be installed using the --no-auto-refresh option, otherwise this feature will shut down the Apache Karaf container. For example:

feature:install -v --no-auto-refresh framework-security

If the DECODE_URL option is true (this is the default value for Fuse 7.11.1 karaf runtime), and use HttpServerExchange to decode relativePath and requestPath, the requestURI parameter remains encoded.

The dispatch methods (forward, include, async and error) assign the path without decoding it, for requestPath and relativeURL, which causes dispatching to a path such as /some%20thing.