Understanding the Log4J/JNDI (Log4Shell) Exploit

When it was introduced in the mid-1990s, the Java programming language was intended to be a small, clean, secure, and highly portable programming language that jettisoned the legacy baggage of languages such as C and C++ and was designed for modern machines with ample memory and processing power. With the Internet “baked in” from inception, it was supposed to allow Web browsers to securely run “applets” that provided local interaction with users within a sandbox to prevent malicious exploitation of systems by nefarious actors.

The key word is “supposed”. The reality was quite different, as rapidly became apparent. The Java slogan “Write once, run anywhere” quickly became mocked by me and many others as “Write once, run anywhere. Yeah, right.” The vast security perimeter of Java proved impossible to defend, and one by one, browser vendors disabled and removed Java to defend their users from incessant attacks, and the “small, clean” language bloated into a monstrosity whose runtime, required simply to run programs on a 64-bit LInux machine is, as of the most current release, a quarter of a gigabyte in size.

Java was supposed to replace legacy languages, but its own legacy is one of language bloat of which the designers of PL/I could only have dreamed, and a litany of security holes and patches stretching over decades. And, most recently, it has launched another torpedo attack on the Internet.

An apparently simple logging package developed by the Apache Software Foundation called Log4J turns out to have a “feature” which allows it to recursively expand macros within strings it writes to its logs. These macros, in turn, can make Java Naming and Directory Interface (JNDI) queries, including those sent to other sites anywhere on the Internet. These can be combined in an exploit named Log4Shell to allow remote execution of arbitrary code on a server innocently using Log4J to log requests from remote clients, resulting in a vulnerability affecting hundreds of millions of devices and called “the single biggest, most critical vulnerability of the last decade”.

The vulnerability was disclosed on 2021-12-09, three days after a patch was issued to “fix” the problem, but it will take years for this this patch to propagate into the myriad vulnerable applications, and Internet bottom feeders have been quick to deploy this attack indiscriminately across the network. This site has seen 27 of these attacks in the Web server log file in the first 12 hours of 2021-12-24 alone. If you run a Web server, search your access log file for the string “${jndi:” and see how many pop out. (This site does not run any Java code at all and hence is not vulnerable, but that doesn’t keep them from trying. The IP addresses from which these attacks originate will be familiar to anyone who’s run a WordPress site and observed the incessant, mindless attacks it attracts.)


It so happens that the SCADA package that dominates my professional life (and for which I write custom add-on functionality) is built on java. With almost two decades of history. It dodged this huge bullet because it switched to logback a few years ago:

(Note the familiar user interface on their forum…)

1 Like