@jason.mcintosh While you could be right, it’s very difficult to say we’re not vulnerable through a static analysis of code, out of an abundance of caution, we are assuming that our agent IS vulnerable and are acting accordingly.
@platform_devops Yes, the
5.7.0 version of the agent uses a version of log4j that is affected by the vulnerability.
is 4.x agent version also affected by this?
@pritkuma Yes, those versions of the agent use log4j versions starting with
2.11.2 - so they are affected by the vulnerability. We recommend that you either upgrade your agent version or use the published workaround - either setting the appropriate system property or environment variable - mentioned on the Apache log4j 2 site.
Hi - If we use Java Agent 5.8.0 and we can not upgrade immediately , can we use the system property set to true
log4j2.formatMsgNoLookups=true to mitigate the vulnerability from the NR agent?
If you’re on Java 7 and are not able to upgrade your Java version, we recommend that you use the published workaround - eg: either defining a system property or using an environment variable as part of your application start.
@Diwakar.K: Answered in your other topic:
yes, starts with 4.12.0
Hi, we are using 5.10.0, if this agent is impacted. what version should we update it it? thanks
Hi, when I look into the javaagent jar files (v5.9.0 & v6.5.0), I do NOT see any log4j jar there and I further assume that NR javaagent will make use of the log4j libraries in the host application. If I am right, what if the main / host application has changed to use log2j 2.15.0 or above or has used the log4j2.formatMsgNoLookups=true workaround, do I still need to upgrade my javaagent to mediate this log4j vulnerability?
Please see updated guidance above. I have to retract this statement. The environment variable will not work to set this for the agent, only the application itself. Please use guidance given above (which has been edited with this new info).
Unfortunately this is not quite accurate.
The Java agent shadows the Log4j classes into the agent jar to avoid conflicts with whatever logging library is used by the host application. The Java agent does not depend on the host application to provide any logging library for the agent logger.
You’ll find the Log4j classes repackaged in the agent jar in the
com/newrelic/agent/deps/ directory along with other shadowed dependencies used by the agent.
We’ve taking steps to update Log4j used for agent logging but the same precautions must be taken for maintainers of the host application and it’s usage of Log4j.
To be clear, both the Java agent and the host application should be updated to use Log4j 2.15.0+ where possible. If you are instead using the
-Dlog4j2.formatMsgNoLookups=true system property workaround the Java agent will respect that.
Thanks @jkeller , if we are running java agent version 5.9.0, is it affected? What is the differences between 6.5.1 and 7.4.1? Which one is using the same configuration schema / format as 5.9.0? Thanks in advance.
Java agent versions 4.12.0 and above (excluding the recent patched versions of 6.5.1 and 7.4.1) all use Log4j 2.11.2 which is an affected version.
The Java agent config yaml schema is consistent across all agent versions and thus there is no real difference between the config for 6.5.1 and 7.4.1 other than newer versions will likely have additional new config options that didn’t exist in prior versions.
Agent 6.5.1 is updated to Log4j 2.15.0 and will address the Log4j issue for users on Java 8 - 15.
Agent 7.4.1 is updated to Log4j 2.15.0 and will address the Log4j issue for users on Java 8 - 17+.
Neither patched version is compatible with Java 7 as Log4j 2.15.0 does not support it, unfortunately.
Beyond that, the only differences are what you can see in the Java agent release notes which are bug fixes, performance improvements, and new functionality unrelated to the Log4j exploit.
Updating to 6.5.1 from the version you’re currently on (5.9.0) will be the quickest and potentially least impactful path to a patched version but we encourage you to check out the latest version as you might just see some cool new functionality that will provide you value.
Thanks @jkeller and it is very clear.
Are New Relic private minions affected by this vulnerability?
We’ve set up dashboards for our various tribes, so they can see if their products are using Java and which versions/agent version. This has been really useful, but we still need to drill down into the APM data via the ‘environments’ to see which version of Log4j is listed in the jars. This does the job but doesn’t provide a top down view, and is quite long winded where we have lots of apps.
Has anyone worked out a NRQL query that’d list all the apps in the account, which are using Log4j < 2.15.0?
“Has anyone worked out a NRQL query that’d list all the apps in the account, which are using Log4j < 2.15.0?”
Also interested in this.
@jkeller I have very basic and scenrio question here.
My Application’s Log4J has already been upgraded to 2.15.0
Since, NR Java agent’s jar has passed to host applicaiton at run time using command line argument. Then how, it becomes vulnerable? b/c whatever the APIs host application have exposed, those got safe gaurded b/c of host application log4j library upgrade. Then what’s the vulnerability can cause by the NR java agent?