Chapter 7. Known Issues

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.

Applications that that use the FasterXML jackson-databind library to instantiate Java objects by deserializing JSON content are potentially vulnerable to a remote code execution attack. The vulnerability is not automatic, however, and it can be avoided if you take the appropriate mitigation steps.

At a minimum, the following prerequisites must all be satisfied before an attack becomes possible:

It is the existence of a large number of gadget classes which explains why there are many individual CVEs related to the jackson-databind vulnerability. There are different CVEs related to different kinds of gadget class.

If you do need to use the jackson-databind library in your application, the most important measure you can take to mitigate the risk is this: avoid polymorphic type handling in Jackson JSON and on no account should you call the ObjectMapper.enableDefaultTyping() method.

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

The Fuse 7.1 on JBoss EAP quickstarts cannot be built, because they are configured with an incorrect version of the Maven BOM (which is not available from the Red Hat Maven repository). To work around this problem, build the quickstarts with the additional Maven option, -Dversion.fuse=7.1.0.fuse-710019-redhat-00002. For example:

mvn clean install -Dversion.fuse=7.1.0.fuse-710019-redhat-00002

A regression was introduced in the Salesforce Camel component, whereby a Salesforce consumer processes exchanges synchronously instead of asynchronously. So if a single Camel route uses the same Salesforce component instance in a consumer endpoint and a producer endpoint, it ends up deadlocked on the HTTP connection in the producer endpoint.

For example, the route below (whether it uses enrich or to for the producer endpoint) will deadlock in the getSObject endpoint:

from("salesforce:syn_Lead_c?sObjectClass=io.syndesis.example.Application$Id&sObjectQuery=SELECT+Id+FROM+Lead")
  .enrich("salesforce:getSObject?rawPayload=true&sObjectName=Lead")
  .convertBodyTo(String.class)
  .to("log:sf?showAll=true&multiline=true");

One workaround is to use a wireTap endpoint like this:

from("salesforce:syn_Lead_c?sObjectClass=io.syndesis.example.Application$Id&sObjectQuery=SELECT+Id+FROM+Lead")
  .wireTap("salesforce:getSObject?rawPayload=true&sObjectName=Lead")
  .convertBodyTo(String.class)
  .to("log:sf?showAll=true&multiline=true");

Another workaround is to break up the Camel route using SEDA endpoints like this:

from("salesforce:syn_Lead_c?sObjectClass=io.syndesis.example.Application$Id&sObjectQuery=SELECT+Id+FROM+Lead")
  .to("seda:sfenrich");

from("seda:sfenrich")
  .enrich("salesforce:getSObject?rawPayload=true&sObjectName=Lead")
  .convertBodyTo(String.class)
  .to("log:sf?showAll=true&multiline=true");

This issue will be fixed in the next Fuse release.