Log4Shell” Java vulnerability – how to safeguard your servers

Apparently, early reports of the bug referred to it as “LogJam”, because it allows you to JAM dodgy download requests into entries in LOG files.

But LogJam was already taken (in that one, LOG referred to discrete logarithms, as performed in cryptographic calculations, not to logfiles).So, Log4Shell it became.

The name?Log4Shell?refers to the fact that this bug is present in a popular Java code library called?Log4j?(Logging for Java), and to the fact that, if successfully exploited, attackers get what is effectively a shell – a way to run any system code of their choosing.

Unfortunately, the vulnerability was tweeted out as a zero-day hole (the name for a security bug that’s documented before a patch is out), and published as a proof-of-concept (PoC) on GitHub, so the world first got to hear about it while it was still unpatched.

The bug, now officially denoted?CVE-2021-44228, involves sending a request to a vulnerable server in which you include some data – for example, an HTTP header – that you expect (or know) the server will write to its logfile.

But you booby-trap that data so that the server, while wrangling the data into a format suitable for logging, kicks off a web download as an integral part of constructing the needed log entry.

And not just any old download: if the data that comes back is a valid Java program (a?.class?file, in the jargon), then the server runs that file to “help” it generate the logging data.

The trick is that, by default, unpatched versions of the Log4j library permit logging requests to trigger general-purpose LDAP (directory services) searches, as well as various other online lookups.

Recommended steps you can take include:

• Upgrade to Apache Log4j 2.15.0.?If you’re using Log4j, any 2.x version from 2.14.1 earlier is apparently vulnerable by default. (If you are still using Log4j 1.x, don’t, because it’s completely unsupported.)
• Block JNDI from making requests to untrusted servers.?If you can’t update, but you’re using Log4j 2.10.0 or later, you can set the configuration value?log4j2.formatMsgNoLookups?to?true, which prevents LDAP and similar queries from going out in the first place.
• Check the Java runtime that you’re using.?The underlying build of Java that you have may prevent this bug from triggering based on its own default configuration. For example, Apache explicitly lists Oracle Java 8u121 as providing protection against this RCE.