TLDR;
Your data is safe with Rollbar.
A zero day in the Java ecosystem was discovered that could exploit Apache’s Log4J library. The vulnerability can, potentially, impact users of Rollbar’s Java SDK if they selected Log4J for their project. We recommend that all projects that are dependent on Log4J upgrade their dependencies so they require a version at/after 2.17.0.
UPDATE: we have updated the guidance so it covers the new Log4J issues (CVE-2021-45046 & CVE-2021-45105) that've been discovered and patched by Log4J. We have published rollbar-java 1.8.1 SDK on Maven and on Github.
What’s the problem?
Log4J, a popular open-source Java logging library, has presented a two zero days that’ve been resolved in the core library. It can allow for malicious code to be executed within the JVM. Log4J has made three point releases since the discovery of the vulnerability, 2.15.0, 2.16.0 and 2.17.0. The current rollbar-java SDK doesn’t log through Log4J explicitly; however, if the customer leverages Log4J as their primary logger then Rollbar’s own logging will go through the affected library.
The vulnerabilities have been labeled by MITRE as CVE-2021-44228 and CVE-2021-45046. CVE-2021-44228 was given the highest CVSS score (10.0) and 2021-45046 is considered LOW. If exploited, the original vulnerability can give an attacker full control of any impacted system.
After learning of the announcement, our security and engineering teams began working diligently to evaluate all of our products and internal services for any potential impact.
Please visit this blog post for the most up-to-date information. If you are a customer and want more information please reach out at [email protected] or speak to your customer support representative.
Is Rollbar’s platform impacted?
After reviewing high-priority infrastructure we see no issues at this time. We have and continue to leverage best-of-breed technology to review every VM & container in our environment to find potential project dependencies related to the affected library.
How are applications that use Rollbar’s Java SDK impacted?
The current Java SDK doesn’t log through Log4J explicitly; however, if the application leverages Log4J as their primary logger then Rollbar’s own logging will pass messages through the affected library.
How can we mitigate the impact?
We provide two paths, but recommend our community move as quickly as possible to our suggested “Full Solution.”
A Stop Gap
We’ve upgraded and released rollbar-log4j (1.8.1) to require the fixed Log4J version as the minimum at/above 2.17.0. Through Java transitive dependencies, this will compel the project to pull the version Rollbar requires or higher, depending on other dependencies listed in the project.
In general, Rollbar’s philosophy is that we set the minimum requirements for our usage to optimize for backwards compatibility, but in this situation we’ve made an exception to protect our customers and their applications from this vulnerability. It’s always in an application's best interest to manage dependencies at the project level rather than relying on plugins and libraries.
Full Solution: Manage Log4J Dependency in Your Project
We recommend that projects always manage their own dependencies rather than rely on our libraries to do so. In general, the Rollbar SDK abides by a philosophy that we set the minimum requirements for our usage. rollbar-log4j declares an API dependency on log4j-core version 2.11.0, but it is compatible with version 2.17.0 (or greater) which includes a fix for Log4Shell and CVE-2021-45046.
In order to fix the vulnerability, projects depending on rollbar-log4j must explicitly declare the log4j version they depend on. The version required by rollbar-log4j will be overridden by this version if it is later.
Note that these examples discuss a 2.15.0 upgrade and the Rollbar version is 1.7.10 (we are at 1.8.1 currently). We recommend updating to 2.17.0 or beyond and recommend Rollbar java users upgrade to 1.8.1 or greater.
For example, an application using rollbar-log4j might include the following dependencies in its build.gradle:
dependencies {
implementation group: 'com.rollbar', name: 'rollbar-log4j2', version: '1.7.10'
}This produces in the following list of runtime dependencies that includes a vulnerable version of log4j, 2.11.0, as a transitive dependency:
runtimeClasspath - Runtime classpath of source set 'main'.
\--- com.rollbar:rollbar-log4j2:1.7.10
+--- com.rollbar:rollbar-java:1.7.10
| +--- com.rollbar:rollbar-api:1.7.10
| \--- org.slf4j:slf4j-api:1.7.25
\--- org.apache.logging.log4j:log4j-core:2.11.0
\--- org.apache.logging.log4j:log4j-api:2.11.0
The vulnerable version can be replaced, without any loss of functionality, by depending on version 2.15.0 directly, so the Gradle dependencies would be:
dependencies {
implementation group: 'com.rollbar', name: 'rollbar-log4j2', version: '1.7.10'
implementation group: 'org.apache.logging.log4j', name: 'log4j-core', version: '2.15.0'
}With this configuration the vulnerable transitive dependency will be overridden by the one chosen by the project:
runtimeClasspath - Runtime classpath of source set 'main'.
+--- com.rollbar:rollbar-log4j2:1.7.10
| +--- com.rollbar:rollbar-java:1.7.10
| | +--- com.rollbar:rollbar-api:1.7.10
| | \--- org.slf4j:slf4j-api:1.7.25
| \--- org.apache.logging.log4j:log4j-core:2.11.0 -> 2.15.0
| \--- org.apache.logging.log4j:log4j-api:2.15.0
\--- org.apache.logging.log4j:log4j-core:2.15.0 (*)The same approach should work in a Maven build.
If you’re using rollbar-struts2, please upgrade Struts.
Updates (recent last)
Update Tues Dec 14th 5:10pm PT: The rollbar-java 1.8.0 SDK is published on Maven and Github. Review the ChangeLog before upgrading.
Update Sat Dec 18: 10:00am PT: Rollbar is aware of the issue and actively investigating what updates, if any, are required by our customers for CVE-2021-45046 beyond upgrading Log4J to 2.17.0.
Update Mon Dec 20: 5:43am PT: Rollbar has published rollbar-java 1.8.1 SDK on Maven and on Github.
