by
Scott Glew
Update – 14th February 2022: If your vulnerability scanner is detecting the log4j-core-*.jar file, you may be able to resolve the issue by deleting the problematic class files within this .jar file. We’ve had confirmation that this process works for the Nessus Vulnerability Assessment tool.
To do this:
Update – 29th Decmeber 2021: We have publicly released a new build for all Fastvue Reporter applications that starts Elasticsearch with the JVM property that mitigates the Log4J vulnerability in Elasticsearch 5.6.14 (the version that Fastvue Reporter uses). Please see our release notes page for information and download URLs.
We are unable to update the version of Elasticsearch used in Fastvue Reporter at this point in time due to compatibility and performance reasons, so Fastvue Reporter will, unfortunately, continue to trigger vunerability scanners. However if you update to our latest version, and you also add the environment variable described in the article below, the vulnerability will be mitigated as per the advice from Elastic.
Updating the version of Elasticsearch used by Fastvue Reporter is on our longer-term roadmap, but we cannot provide an ETA at this point in time.
Update – 20th Decmeber 2021: Elastic have now confirmed that the version of Elasticsearch used by Fastvue Reporter (5.6.14) does not use the Java Security Manager mentioned in the update below. This means you must follow the steps below to add the environment variable and restart the Fastvue Reporter service. This starts Elasticsearch with the JVM property that mitigates the vulnerability. Fastvue will release an update soon that launches Elasticsearch with the JVM property by default.
Update – 12th December 2021: Elastic have since downgraded the issue saying”Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager” which is good news:
https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476However, we still recommend adding the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to your servers. Especially if you have other services installed that could also be using log4j under the hood. There are many of them out there!
But at this stage, it looks like running Fastvue Reporter, even without the environment variable is very low risk.
If you’re in the infosec space, you have no doubt heard about the Log4j vulnerability that is setting the internet on fire right now.
Fastvue Reporter uses Elasticsearch as its database, which uses Log4j for its own diagnostic logging.
Elastic is currently investigating the issue and we will update Fastvue Reporter asap, but in the meantime, we recommend adding an environment variable to your Fastvue Server in order to mitigate the vulnerability.
To do this:
LOG4J_FORMAT_MSG_NO_LOOKUPS
This short video shows how to mitigate the Log4j vulnerability on Windows servers running Fastvue Reporter.
Please follow these steps as soon as possible to avoid the Log4j vulnerability causing issues in your infrastructure.
We will update this article when a patch for Fastvue Reporter is available.
To stay updated with Fastvue’s product and security updates, keep an eye on our Release Notes, subscribe to our mailing list making sure you check the Product Updates & News checkbox, and/or follow us on LinkedIn, Twitter or Facebook.
Download Fastvue Reporter now and try it free for 30 days or schedule a demo and we'll show you how it works.