Log4Shell vulnerability in log4j

Published

Update: There's a Computerphile video (26 minutes) explaining just how bad this issue is.

Update: The Apache people maintaining log4j have announced that the fix in 2.15 was “incomplete in certain non-default configurations,” and so now recommend upgrading to version 2.16.0.

So in the last 24–48 hours one of those periodic big vulnerabilities got everyone excited. Apparently the Java library log4j 2 has a remote code exploit. It has a feature where the log message formatting can include code that does an LDAP query and executes the code returned.

Worse, it seems like this formatting code will be expanded after the first round of formatting/templating that the software will have configured for its logs, so it will be applied to text inserted by that first step. I could be misreading exactly how it plays out, never having worked with log4j, but people have been exploiting it by putting the exploit code in things like usernames and DNS queries. It seems what should be untrusted outside input—information that should be copied verbatim into a log file—is being expanded as if it were trusted log configuration.

I heard the details first from LunaSec's analysis. They've decided to call it Log4Shell.

Mitigations and fixes

There is apparently an option to not do this crazy external lookup dance. It's just that it's unsafe by default and very few people are likely to have known about or addressed that until now. Upgrading to 2.15.0 now fixes the problem though. Here's the Apache.org announcement (they host the project):

The Log4j team has been made aware of a security vulnerability, CVE-2021-44228, that has been addressed in Log4j 2.15.0.

Log4j’s JNDI support has not restricted what names could be resolved. Some protocols are unsafe or can allow remote code execution. Log4j now limits the protocols by default to only java, ldap, and ldaps and limits the ldap protocols to only accessing Java primitive objects by default served on the local host.

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it.

Log4j in LibreOffice

The only things I've had to contend with, since I don't deal with much Java: on my own machine I uninstalled the Debian Buster package liblog4j1.2-java.

I only later realised that this is the old log4j v1. I've no idea if that's vulnerable as well as v2, but better safe than sorry I suppose. The only interesting thing that had to go because it held a dependency was something called ‘libreoffice-report-builder’. I'd never heard of that, but according to the package description:

Create with the Sun Report Builder stylish, smart-looking database reports. The flexible report editor can define group and page headers as well as group and page footers and even calculation fields are available to accomplish complex database reports.

Sounds interesting I suppose, but it can go for now.

Jitsi

More importantly I maintain a Jitsi video conferencing installation (like Zoom but Free Software, and inexplicably written in Java). The package ‘jitsi-videobridge2’ contains two Jar files for log4j. These are them after I upgraded to the version of the package published yesterday:

That upgrade to version 2.1-595-g3637fda4-1 seems to fix the problem by bringing in the fixed log4j v2.15