Skip to main content

Find and Fix Log4j

In December 2021, a zero-day Remote Code Execution exploit was discovered in the component, log4j-core, the most popular Java logging framework. The log4j-core vulnerability (CVE-2021-44228, a.k.a. Log4Shell) affects a massive number of applications and businesses. Essentially any application that contains a vulnerable version of log4j-core is exploitable.

Note

It has been determined that the fix for CVE-2021-44228 committed in v2.15 was insufficient in limiting nested message lookups in log4j. This resulted in CVE-2021-45046—a Security High vulnerability on v2.15. In addition, a Denial-of-Service (DoS) vulnerability (CVE-2021-45105) has been discovered in v2.16. It is recommended that all users upgrade to version 2.17.1.

Select the Sonatype solution you wish to use

Sonatype Lifecycle

The following information helps Lifecycle users find and fix log4j-core vulnerabilities.In addition, we've created a short video that walks you through this topic:

How do I know if my applications are affected by the log4shell vulnerability (CVE-2021-44228)?

I have scanned my application(s) since December 11, 2021

Your Dashboard results will show the most recent violations.

The Dashboard is displayed by default when you log into Lifecycle. You can also access it by clicking the Dashboard

Click the Filter button to adjust your results. For example, you can filter by the highest security threats within the desired time range.

Click Apply in the Filter menu to view your results

Click the Export Violations Data button to save a CSV of the results

I scanned my application(s) prior to December 11, 2021

If you scanned your application before the vulnerability was known, use the Component Search REST API to search for the component. The following curl will generate an output.txt file with all versions of log4j-core, including those that are not vulnerable. A more complete demonstration can be found in the nexus-iq-api-scripts repo on the Sonatype Community Github.

rm -rf output.txt; for i in {"build","stage-release","release","operate"}; do curl -u admin:admin123 -X GET "http://localhost:8070/api/v2/search/component?stageId=$i&componentIdentifier=%7B%22format%22%3A%22maven%22%2C%22coordinates%22%3A%7B%22groupId%22%3A%22org.apache.logging.log4j%22%2C%22artifactId%22%3A%22log4j-core%22%2C%22version%22%3A%22%2A%22%2C%22extension%22%3A%22%2A%22%2C%22classifier%22%3A%22%2A%22%7D%7D" >> output.txt; done

Note

Note: Update the above with your credentials and IQ Server address.

Note

The best practice for identifying log4j-core components in your application is to run a full, new scan. Avoid using re-evaluate in this situation. Clicking the Re-evaluate Report button on an existing reportreapplies policies to the scan data, and the vulnerabilities do not change.

I have never scanned my application(s)

You will need to onboard your application to Lifecycle.

You can then run a scan via the CLI to get results.

The following example shows the command line for an Application ID Test123 and a URL of http://localhost:8070 . Replace <version> in the jar file path with your version of the CLI.

java -jar ./nexus-iq-cli-<version>.jar -i Test123 -s http://localhost:8070 -a username:password -t release sample-application.zip

log4j-core is in my application. How do I fix it?

I can upgrade my component

We recommend upgrading to a version of this component that is not vulnerable to this specific issue.The best option is to upgradelog4j-coreto a newly released, non-vulnerable version immediately.

For Java 8 and later, upgrade to release 2.17.1

For Java 7, upgrade to release 2.12.4

For Java 6, upgrade to release 2.3.2

Note

If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or potential mitigating control.

I cannot upgrade my component

We strongly recommend upgrading to a non-vulnerable version of log4j-core. If that is not possible, Apache recommends using the following mitigating controls.

In any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Reference: https://logging.apache.org/log4j/2.x/security.html

Note

If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or potential mitigating control.

How do I protect my applications going forward?

Enable Continuous Monitoring

The best practice is to turn on the Continuous Monitoring feature. Continuous Monitoring lets you use existing policies with notifications to constantly watch (once a day, based on your configuration) for new violations at a specific development stage (such as Release). Configure Continuous Monitoring in two steps: (1.) turn it on for an application or organization, and then (2.) turn it on at the policy level and set your notifications.

To turn on Continuous Monitoring for an application or organization:

  1. Select Organization & Policies icon from the left navigation bar

  2. Select the organization or application whose policies you want to monitor.

  3. Under Continuous Monitoring, click the chevron next to Inherit from Root Organization (Do not monitor).

  4. In the Continuous Monitoring view, click the desired stage.

  5. Click Update to turn on Continuous Monitoring.

The next step is turning on Continuous Monitoring at the policy level. This lets you identify who should receive an email message when a violation of the current policy occurs.

To turn on Continuous Monitoring in a policy:

  1. In the Organization & Policy area, create a new policy or open an existing one for an organization or application.

  2. In the Policy editor, click the Notifications button to scroll to the Notifications section.

  3. Make sure the Notifications Recipient list contains the desired email address to use for policy violation notifications. If necessary, add a new recipient.

  4. For the desired email address, click Continuous Monitoring to select it.

  5. Click Update to save the policy.

Turn on email notifications

Lifecycle can be configured to send email notifications for events such as policy violation notifications. Email is a simple way to start getting notifications to the application security team, and eventually developers once they have been notified to expect them.

This functionality requires an SMTP server, which is configured along with a number of other options in the Mail Configuration section of the config.yml file.

Email notifications from the IQ Server are automatically sent to recipients when a policy alert occurs. The email contains information about the application and violation and provides a link to the full results for further investigation.

Sonatype Firewall

The following information helps Sonatype Firewall users identify if log4j-core exists in your repository and prevent future downloads of vulnerable versions of log4j-core.

How do I determine if my organization is impacted by the latest vulnerability disclosure?

Firewall can audit component downloads from a given proxy repository (Java, .NET, npm, Python). You can view a report that contains all components that have been previously downloaded to your Nexus Repository through that applicable proxy repository.

This report can be reviewed for any instance of log4j-core, and you can search for a particular log4j-core component. In addition, the Firewall results include Sonatype-curated vulnerability information—for this CVE and others—only available to Sonatype Firewall and Lifecycle customers.

If this component is found, it indicates it was previously downloaded into your Nexus Repository. As a result, the component is available to applications with privileges to access that proxy repository. To associate a component to a specific application, please visit Sonatype’s Nexus Vulnerability Scanner (NVS) a no-cost scan tool. If you have numerous applications to analyze, we recommend reaching out to Sonatype Sales to trial the Lifecycle solution.

Note

Firewall will not block the log4j-core component if it is already in your repository.

How should we remediate this issue?

We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The best option is to upgrade log4j-core to the newly released, non-vulnerable version immediately. This is currently version 2.17.1. However, given this is a fast-moving and fluid situation, there may be a newer version released as you are reading this guide.The fixed version for this issue was released by Apache and isavailable via Maven Central .

How can Firewall help with other known vulnerabilities?

In addition to auditing component downloads, Firewall is designed to quarantine component download requests based on policy configuration. You can configure the policy to quarantine new component downloads for known vulnerable versions of any component based on any range of criticality.

Nexus Repository

The following information helps Nexus Repository users identify if log4j-core exists in your repository.

Use the log4j Visualizer (Nexus Pro and OSS users)

How do I determine if my organization is impacted by the latest vulnerability disclosure?

In an effort to help the global software community defend itself against this threat, Sonatype is providing an experimental Log4j Visualizer to all Nexus Repository OSS and Pro users to provide greater visibility into Maven log4j component downloads impacted by CVE-2021-44228.

Note that the Log4j Visualizer only captures information about the log4j.core component in Maven and only identifies those impacted by CVE-2021-44228. It does not currently identify or track other log4j vulnerabilities.

Note

Sonatype is providing this Log4j Visualizer for a limited time to all Nexus Repository OSS and Pro users due to the urgent threat that the log4j vulnerability poses to the global software community. Access and use of the Log4J Visualizer are governed by the terms of your agreement with Sonatype or, in the absence of such, these terms. We may update or remove this feature completely in future versions.

How should we remediate this issue?

To help mitigate the impact of any log4shell downloads, we have provided the following recommendations:

Short-Term Recommendations

  1. Encourage development teams to upgrade their log4j dependencies to a non-vulnerable version.

  2. Don’t delete vulnerable log4j versions from your repositories except as a last resort. Fixing critical problems can be harder when missing dependencies cause builds to break.

  3. Stay up to date on the latest Log4j developments.

Longer-Term Recommendations

  1. Consider reducing anonymous access to your repositories so that you can more easily understand who is consuming vulnerable dependencies.

  2. Block vulnerable open-source components and malicious attacks from being downloaded into your repositories using Firewall.

  3. Reduce remediation time by using Lifecycle for continuous application monitoring.

Use Repository Health Check (Nexus Pro users only)

How do I determine if my organization is impacted by the latest vulnerability disclosure?

Repository Health Check (RHC) can audit component downloads from a given proxy repository. Users can view a report that contains all components, which have been previously downloaded to your Nexus Repository through that applicable proxy repository.

This report can be reviewed for any instances of log4j-core. Users can also search for a particular log4j-core component. In addition, the RHC report includes links to the associated CVE.

If this component is found, it indicates it was previously downloaded into your Nexus Repository. As a result, the component is available to applications with privileges to access that proxy repository. To associate a component to a specific application, please visit Sonatype’s Nexus Vulnerability Scanner (NVS) a no-cost scan tool. If you have numerous applications to analyze, we recommend reaching out to Sonatype Sales to trial the Lifecycle solution.

How should we remediate this issue?

We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The best option is to upgrade log4j-core to the newly released, non-vulnerable version immediately. This is currently version 2.17.0. However, given this is a fast-moving and fluid situation, there may be a newer version released as you are reading this guide. The fixed version for this issue was released by Apache and is available via Maven Central .

How can Repository Health Check (RHC) help with other known vulnerabilities?

Enabling RHC on all supported repository types provides insight into component downloads across your proxy repositories. In addition, the report includes trend analysis determined by month-to-month component downloads.

Additional Resources