Schlagwort: cloud computing

Apache Log4j 2 CVE-2021-44228

We know that many of you are working hard on fixing the new and serious Log4j 2 vulnerability CVE-2021-44228, which has a 10.0 CVSS score. We send our #hugops and best wishes to all of you working on this vulnerability, now going by the name Log4Shell. This vulnerability in Log4j 2, a very common Java logging library, allows remote code execution, often from a context that is easily available to an attacker. For example, it was found in Minecraft servers which allowed the commands to be typed into chat logs as these were then sent to the logger. This makes it a very serious vulnerability, as the logging library is used so widely and it may be simple to exploit. Many open source maintainers are working hard with fixes and updates to the software ecosystem.

We want to help you as much as we can in this challenging time, and we have collected as much information as possible for you here, including how to detect the CVE and potential mitigations. 

We will update this post as more information becomes available.

Am I vulnerable?

The vulnerable versions of Log4j 2 are versions 2.0 to version 2.14.1 inclusive. The first fixed version is 2.15.0. We strongly encourage you to update to the latest version if you can. If you are using a version before 2.0, you are also not vulnerable.

You may not be vulnerable if you are using these versions, as your configuration may already mitigate this (see the Mitigations section below), or the things you log may not include any user input. This may be difficult to validate however without understanding all the code paths that may log in detail, and where they may get input from. So you probably will want to upgrade all code using vulnerable versions.

The configuration for the docker scan command previously shipped in Docker Desktop versions 4.3.0 and earlier unfortunately do not pick up this vulnerability on scans. Please update to Docker Desktop 4.3.1+ with docker scan 0.11.0+, which we released today, 11 December 2021.

If you are using docker scan from Linux you can download binaries from GitHub and install in the plugins directory as explained in the instructions here. We will soon update the Linux CLI version to include the updated docker scan.

If you use the updated version, you should see a message in the output log like this:

Upgrade org.apache.logging.log4j:log4j-core@2.14.0 to org.apache.logging.log4j:log4j-core@2.15.0 to fix
✗ Arbitrary Code Execution (new) [Critical Severity][https://snyk.io/vuln/SNYK-JAVA-ORGAPACHELOGGINGLOG4J-2314720] in org.apache.logging.log4j:log4j-core@2.14.0
introduced by org.apache.logging.log4j:log4j-core@2.14.0

To test this, you can check a vulnerable image, for example this image contains a vulnerable version.

docker scan elastic/logstash:7.13.3

or to cut out all the other vulnerabilities

docker scan elastic/logstash:7.13.3 | grep ‘Arbitrary Code Execution’

For more information about docker scan, see the documentation.

Docker Hub Scans

Docker Hub security scans are currently not picking up the Log4j 2 vulnerability. We are working to fix this as soon as we can, and to re-scan existing images so you can see which ones are vulnerable. We apologise for this, and will update here as soon as we have fixed this. Please use docker scan from the updated version above until this has been remedied.

Mitigations

You may well want to use a web application firewall (WAF) as an initial part of your mitigation and fix process.

For containerized applications, if the version of Log4j 2 you are using is 2.10.0 or later, there is an environment variable or Java command line option you can use to disable the unsafe substitution behaviour. You can add the line:

ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true

to your Dockerfile, or you can add the equivalent flag “-Dlog4j.formatMsgNoLookups=true” to the command you run in your container, for example:

CMD [”java”, “-Dlog4j.formatMsgNoLookups=true”, “-jar”, “…”]

Both of these are equivalent. You can see how this works with an example proof of concept repo.

You can also configure the environment variable at runtime, which can be easier, for example for Kubernetes you could add these lines into your configuration.

spec:
containers:
– name: …
image: …
env:
– name: LOG4J_FORMAT_MSG_NO_LOOKUPS
value: “true”

For Docker Compose you can use something like:

web:
environment:
– LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Docker Official Images

A number of the Docker Official images do contain the vulnerable versions of Log4j 2. The ones that we believe may contain vulnerable versions of Log4j 2, at the time of publishing this blog:

couchbase 

elasticsearch 

flink 

geonetwork 

lightstreamer 

logstash

neo4j 

nuxeo 

solr 

sonarqube 

storm 

xwiki 

We are in the process of updating Log4j 2 in these images to the latest version available. These images may not be vulnerable for other reasons, and you can check for this on the upstream websites.

In the meantime, for your running applications using these images, see Mitigations above for information on how you can set the environment variable at runtime to mitigate the CVE. Please note: geonetwork and logstash both use earlier versions of Log4j 2 for which the environment variable mitigation does not work, so you will not be able to mitigate these two in this way.

If you use other images as a base (such as openjdk) that do not have affected versions of Log4j 2, it is possible you may be adding Log4j 2 as part of your build on top of an unaffected image and will need to update your Log4j 2 dependency to the latest fixed version.

Other images on Docker Hub

We are working with the Docker Verified Publishers to identify and update their affected images. We are looking at ways to show you images that are affected and we will continue to update this post as we have more information.

Is Docker’s infrastructure affected?

Docker largely uses Go code in our applications, not Java. Although we do use some Java applications, we have confirmed we are not vulnerable to CVE-2021-44228.
The post Apache Log4j 2 CVE-2021-44228 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/