How to avoid Log4J exploit? [closed]

Question

There is a serious security flaw in Log4J that has apparently been patched. But I have not found an intelligible explanation as to how there could even be a security flaw in a logging framework.

It seems to have something to do with "Lookups". https://logging.apache.org/log4j/2.x/manual/lookups.html

But that is in a config file, not a log file that could be injected into?

Question. How do I kill all clever stuff once and for all to prevent any future exploits? I just want logging.

It smells like I need to remove any "$" signs but that is just a guess. (One should also remove any \ns to avoid log file spoofing. I always write a very simple wrapper for the logging to be able to do this sort of thing.)

(I have a very simple shim that all log messages go through, so it is easy for me to remove all "$"s that are not in format strings.)

Answer 1

The only way to prevent vulnaribilites caused by lookups is to disable them completely.

According to log4j2 team, the way to do that is by appending Java parameter

-Dlog4j2.formatMsgNoLookups=true

This definitely fixes the ability to call lookups by putting ${...} sequence s in the user input (like in URLs that are logged).

Unfortunately, the lookups are applied to the logged sequence, even if you use parameters or log exception stack traces. The lookups sequeces in your code are not dangerous, because they are controllable. But those that come from user are not predictable. If you log 'wrong username: xxx', you have no idea, what the user can type to exploit another vulnaribility.

However, you can't be sure there are no other grave errors in the framework, so switching to other logging framework is reasonable.

A good candidate is Logback, which is started by the original author of the Log4j. The developer states clearly, his framework has nothing to do with the security issues introduced in Log4j2:

Unless specified otherwise, when we say log4j we mean log4j 1.x. We should also like to emphasize that logback is unrelated to log4j 2.x. It does not share code nor vulnerabilities with log4j 2.x.

The bug is apparently fixed in the version 2.16.0, however it addresses only that particular vulnaribility, and the dangerous lookup feature was not removed.

According to the Sophos Report,

The updated version of Log4j still supports the potentially dangerous what-you-see-is-not-what-you-get system of string “lookups”, but network-based JNDI connections, whether on the same machine or reaching out to somewhere else, are no longer enabled by default.

In other words, log4j2 still remains unsecure, but not as ridiculously insecure as previously.