Difference between revisions of "Development/Security/Log4j-2021-12"

Latest revision as of 08:34, 17 December 2021

Main Page > Development > Development/Security > Development/Security/Log4j-2021-12

• Posted: 2021-12-13
• Last updated: 2021-12-17

Change log

• 2021-12-13 - Initial page content added
• 2021-12-14 - Add clarifications and explanation why AM and AtoM solutions are different
• 2021-12-15 - Add change log; Update AM instructions to include recommendation to upgrade ES first
• 2021-12-16 - Link to AM wiki instead of duplicating instructions
• 2021-12-17 - Update changelog

Below is the latest information and recommendations we have about CVE-2021-44228, colloquially called the "Log4Shell" vulnerability found in Apache Log4j in December of 2021.

What is this issue that everyone seems to be talking about?

From LunaSec, one of the first companies to write about the vulnerability:

On Thursday (December 9th), a 0-day exploit in the popular Java logging library log4j (version 2) was discovered that results in Remote Code Execution (RCE) by logging a certain string.

Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe. We're calling it "Log4Shell" for short.

The 0-day was tweeted along with a POC posted on GitHub. It has now been published as CVE-2021-44228.

While full server control is the worst possible outcome, the vulnerability could lead to information disclosure or other remote code execution as well. Since the above post was made on December 12th, 2021, the "Log4Shell" name for this vulnerability has been generally adopted (though it is also sometimes referred to as "LogJam").

Another explanation from Ars Technica:

Log4J is an open source Java-based logging tool available from Apache. It has the ability to perform network lookups using the Java Naming and Directory Interface to obtain services from the Lightweight Directory Access Protocol. The end result: Log4j will interpret a log message as a URL, go and fetch it, and even execute any executable payload it contains with the full privileges of the main program. Exploits are triggered inside text using the ${} syntax, allowing them to be included in browser user agents or other commonly logged attributes.

...The vulnerability, tracked as CVE-2021-44228, has a severity rating of 10 out of 10. The zero-day had been exploited at least nine days before it surfaced.

What does Log4j have to do with Elasticsearch?

Elasticsearch is the search index library used in AtoM and Archivematica to support indexing, browsing, and search functionality.

Elasticsearch uses the Log4j library to handle logging. Even if you have not actively configured additional logging, the package will have been installed when installing Elasticsearch as part of your AtoM or Archivematica installation.

For more detailed information from the Elastic team, see:

• https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476

What does Log4j have to do with Java?

Log4j is a Java based tool. Java is a programming language and computing platform first released by Sun Microsystems in 1995, and currently maintained by Oracle. Java is a general term used to denote both the software and its components, which include 'Java Runtime Environment' (JRE), 'Java Virtual Machine' (JVM) and also 'Plug-in'.

The vulnerability is not caused by Java directly, but rather how Log4j handles requests. However, ensuring you have the most up-to-date version of Java installed is always a good idea, and the Oracle Java website also includes further general tips for ensuring the security of your Java installation:

• https://www.java.com/en/download/help/security-tips.html

You can review Oracle’s announcement about this vulnerability on their blog, here:

• https://blogs.oracle.com/security/post/cve-2021-44228

Do I need to do anything about this? Am I vulnerable?

If you are an Artefactual hosted client, or if you have a maintenance agreement with Artefactual, then there is nothing you need to do - hosted clients have already been patched, as have most maintenance clients - if Artefactual needs to coordinate with you for support access and/or patching, our team will be in touch shortly if they have not been already.

If you are using a different hosting provider, we recommend that you contact them to verify that this issue is being addressed.

If your organization is hosting your own AtoM installation, then yes: you will need to ensure that your server is patched against the vulnerability to prevent information leakage.

What has Artefactual done about this vulnerability?

Our team has been monitoring all developing information, and using it to perform our own penetration tests to determine both the severity of the issue, as well as ensure that the recommended patch solutions correctly resolve the vulnerability.

Based on these findings, our team has already patched all Artefactual-hosted applications (and most maintenance agreement installations) affected by this vulnerability, and are in the process of coordinating with any locally maintained installation owners with a maintenance agreement where communication is required to perform the necessary patching.

We will continue to monitor developments, perform our own tests to ensure that any proposed solutions do in fact resolve the issue, and will be keeping a close eye on the logs for all hosted and maintained installations.

To support our user community, we have also prepared this FAQ with guidance on how best to secure your local installation.

Can my AtoM or Archivematica instance end up running dangerous executable code because of this?

Fortunately, the risk of this occurring appears to be low. There is some risk of information leakage, but based on current public sources as well as our own internal penetration testing thus far, currently it appears there is a very low risk that it’s possible to trigger executable code via an Elasticsearch query with this vulnerability.

As the Elastic team reports:

Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch on JDK8 or below is susceptible to an information leak via DNS which is fixed by a simple JVM property change. The information leak does not permit access to data within the Elasticsearch cluster. We will also release a new version of Elasticsearch that contains the JVM property by default and removes certain components of Log4j out of an abundance of caution.

However, this is clarified later with:

Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Investigation into Elasticsearch 5 is ongoing.

At this time, AtoM 2.6.0 and later versions use Elasticsearch 5.6.

Additionally, most Archivematica installations are not publicly accessible, further reducing the likelihood of a successful attack using this vulnerability.

Despite the above, this is a developing situation and, we still strongly recommend that all AtoM and Archivematica users patch the vulnerability as soon as possible.

What is the recommended fix for this vulnerability?

If we discover further information that contradicts the current recommendations, we will edit this page with updates and links to further sources.

In the meantime, based on the different versions of Elasticsearch used in AtoM and Archivematica, below are the least disruptive ways we have found to ensure your installation is no longer vulnerable:

Archivematica

Please follow the instructions on the Archivematica wiki

Atom

Please follow the instructions on Step 5 of this guide:

• https://www.geekyhacker.com/2021/12/11/three-ways-to-patch-log4shell-cve-2021-44228-vulnerability/

In short, as root:

• Install the zip package: apt-get install zip (Debian/Ubuntu) or yum install zip (RedHat/CentOS)
• Change directories: cd /usr/share/elasticsearch/lib/
• Run the following line to remove the problematic file:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

• Restart the ElasticSearch service with: service elasticsearch restart

Why are the recommended fixes different for AtoM and Archivematica?

The most important distinction is that AtoM is using Elasticsearch 5.x, while Archivematica is using Elasticsearch 6.x.

The ES_JAVA_OPTS variable solution recommended for Archivematica will only work Log4j releases later than 2.10, which will always be the case with Elasticsearch 6 installations.

Meanwhile, with Elasticsearch 5, and the fact that AtoM 2.6 has been out for some time, this is not a guarantee - older ES 5.x installations may include a Log4j version earlier than 2.10 - in which case, the ES_JAVA_OPTS solution will not take effect. By proposing the zip deletion solution, we are offering a method that should work for all 2.x versions of Log4j, and which is much easier than trying to upgrade Log4j in place without disrupting your AtoM installation.

Our team found the following article very helpful in better understanding the options and pros and cons of each:

• https://www.geekyhacker.com/2021/12/11/three-ways-to-patch-log4shell-cve-2021-44228-vulnerability/

Where can I get more technical information for my IT team?

CVE: CVE-2021-44228

(Learn more about what a CVE is here and here)

Our team found this document very helpful for outlining some of the different options for addressing the vulnerability:

• https://www.geekyhacker.com/2021/12/11/three-ways-to-patch-log4shell-cve-2021-44228-vulnerability/

Some other sources we have found to be reliable and regularly updated:

• Elastic security announcement on CVE-2021-44228, December 10, 2021
• Apache Log4j security announcement page
• LunaSec blog post on Log4Shell, December 12, 2021
• Oracle Security blog announcement on CVE-2021-4428, December 10, 2021

• Back to Security announcements
• Back to Development
• AtoM wiki home