Released: Dec 13, 2021

CVE2021-44228: Log4shell RCE

Given the massive interest in this CVE of the log4j2 library, we decided to release a hotfix version.

Backend

Although we are using Java in the backend, log4j2 is not implemented directly, only via Spring Boot.

The Spring Boot team is quite clear about the potential risk:

The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable.

Source

Portrait does not make use of log4j-core. Nevertheless, we followed their recommendation and overwritten the dependency for log4j in the hereby released version 4.0.1.

Index

Also, our data-index uses Log4j 2.11.1 – which would be an affected version. However, Elasticsearch implemented a Java Security Manager which prohibits loading data or remote code from the logging library.

Elastic’s official statement:

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.

Source

The above-mentioned possibility of an information leak through DNS is however, not applicable for Portrait: Neither we are using an old JVM (this risk only applies to JDK older than version 9) or environment variables that would expose critical data.

Good news is, we already implemented Elasticsearch 7.16.1 and are already testing this version. This ES version will be shipped with Portrait 4.0.2.

Caching-policy for files

The UX for big sections was not satisfying, since images were always reloaded and the list flickered on scroll.

Proxy

The caching definition was divided for the /api route: files loaded via the API are treated different than data that comes from the backend. This will speed up page load and will lead to a better user experience.