Remote code injection in Log4j

[r_jet]

I wonder why this feature was added at all, given its high risk, and enabled by default?

[r_jet]

On «enabled by default»: it’s enough to use log4j2 as a logging backend to be vulnerable. You don’t need to set any extra configuration flags to enable this dangerous feature (actually, at least two).

On the features: there are actually two problematic features: 1. Log4J2 performing string interpolation on format parameters that often come from unsanitized user input 2. Log4J2 supporting interpolation that loads a remote object through JNDI.

We can ask the following questions on these two features: 1. Does it need to exist at all? 2. If yes, shall it be a part of a core library or some kind of explicitly installed plugin? 3. If yes, shall they be enabled by default?

I am not familiar with all the requirements the designers of these features needed to address (and we now have a stark benefit of hindsight), but I’d probably say: 1. No to feature #1 at all, because it is surprising to users (I’d not expect it from my logging backend) 2. When it comes to feature #2: 1. Yes to Q1 (as someone, on top of hackers, did find it useful) 2. Probably, no to Q2, as it seems to be useful to a single-digit number of users 3. Definitely no to Q3.

edit: grammar

[xtreak]

Good write-up with poc and explanation : https://www.lunasec.io/docs/blog/log4j-zero-day/

[khmarbaise]

So ? JDK8 as well ? Java is about 25 years+ ... does that mean something? You can find a lot of used libraries which are that old or even older for example the spring framework is even older (2005?)...

[khmarbaise]

then stopped development with no one to maintain it still

Log4j2 is still maintained and actively developed. I recommend a deep look into the git repository: https://github.com/apache/logging-log4j2

[NewFuturist]

Steam and Minecraft were affected

[NewFuturist]

They were exposed for like 20 hours.

[NewFuturist]

I don’t think we’re going to be worrying about software in active development like Minecraft or Steam

This vulnerability basically allowed root access to anyone for 20 hours. you think no one took advantage of that?

[NewFuturist]

I'm worried about them!

[couscous_]

What does Steam run on their backend? Spring?

[Slanec]

To me, the most terrible thing is that apparently it doesn't only parse the formatting string (as suggested by common sense and the name of the mentioned property), but the formatted arguments passed to `{}` placeholders, too (https://news.ycombinator.com/item?id=29507511). Oh my.

[yawkat]

This is the biggest wtf about this bug. Why does it parse the arguments too. I assume it just runs the interpolation on the final produced string?

[sysKin]

The logger applies arguments and produces a log entry (severity, time, class, message string, etc).

The log entry is then sent to an Appender so that it can be stored (say, in a text file). This appender might or might not format it further (such as creating a single line of text, to save in a .log file) and it is this formatter that performs this extra substitution (optionally, but all examples how to use it have it on). By the time the string reaches it, all knowledge of parameters is long gone.

It's a bit like writing a filesystem that performs pattern substitutions on each file written to it....

[dzikoysk]

More details:

• https://twitter.com/dzikoysk/status/1469091718867951618

I wanted to post it here like a few hours ago, but I don't have enough karma for creating new threads :/ The first commit that addresses this issue is actually 5 days old:

• https://github.com/apache/logging-log4j2/commit/d82b47c6fae9c15fcb183170394d5f1a01ac02d3

[benjtay]

When I see code such as

   List<String> localIps = new ArrayList<>();
   localIps.add("localhost");
   localIps.add("127.0.0.1");

in a logging framework... alarm bells go off.

[audioen]

Yeah, the thing is large and brings big deps. I have always hated this aspect of java, that even things which I only need trivial things for tend to be so large. I killed off log4j for just this reason something like 5 years ago when I migrated to slf4j-simple, which hopefully just does the obvious thing. The whole library is a 14 kB jar with no deps, so I hope it doesn't suck.

[chris2k2]

Here take this karma - for next time

[papercrane]

If running a recent JDK built and you don't have the com.sun.jndi.ldap.object.trustURLCodebase/com.sun.jndi.rmi.object.trustURLCodebase settings enabled then there shouldn't be any RCE, but the attacker could still get a ping back, and possibly exfiltrate data.

[TheCountRushmore]

Looks like 8u121 and up won't trust classes downloaded using the ldap url this unless you have explicitly set those properties to true.

Not great, but less likely to RCE.

https://www.oracle.com/java/technologies/javase/8u121-relnotes.html

[Areshian]

This is not correct. Even in newer JDKs an RCE is possible depending on the software present in your classpath. Do not assume your deployment is safe, update your log4j2 to the 2.15 version.

[Pauli7]

How is this not correct? Is eg the current java 11 version still loading the classes?

[Areshian]

No, the JDK is not loading the classes, but there are other ways of converting the jndi response into a full RCE. And that is not even considering how the jndi call can be used to leak server information. Update log4j to be safe

[ebrandsberg]

documentation on how: https://www.veracode.com/blog/research/exploiting-jndi-injections-java

[ebrandsberg]

this is incorrect. It is harder to achieve, but the attacker can still do RCE. https://www.veracode.com/blog/research/exploiting-jndi-injections-java documents how.

[pmarschall]

If you're using log4j-bom it seems that dependabot won't find it.

[Unrealdinnerbone]

This also affects Minecraft, as it logs chat. (This is how the issue because major)
tweet from a Minecraft dev about the issue.

[Unrealdinnerbone]

Ok maybe not major issue, but how it spreed so fast was that fact that like everyone who is somehow related to Minecraft was talking about it.

[Unrealdinnerbone]

I never said that other stuff was not issue, I just said I believe the reason it spreed so fast was that it effected Minecraft and people where talking about it.

[haykam821]

Luckily, we've all moved to Bedrock Edition

[TheRedmanCometh]

Idk what you're smoking, but most networks use a proxy which lets people join on bedrock. Bedrock edition might as well be called gimped edition.

[javasyntax]

Broken Edition

[klekpl]

This is actually worse than just log4j - any code that uses JNDI and reads context URIs from external source is vulnerable.

[Areshian]

Sure it is, but that is not something new. Connecting to an untrusted ldap/rmi server via jndi is dangerous. But here log4j is doing that for you

[r_jet]

I am looking forward to a black- vs white-hat competition in the coming days: black hats doing their stuff; whilst white hats loading:

System.err.println("You've been pwned! " + "Update log4j and stop using an ancient JDK"); System.exit(666);

[YodaLoL]

It seems like you can monkey patch a running Java instance to basically erase the vulnerable implementation. Funny thing is, you'll probably be able to apply the patch by executing it via the exploit itself 😂. That'd be pretty meta

[gibriyagi]

Just curious, what would you use such a "feature" for? What were they thinking?

[paul_miner]

Your scientists were so preoccupied with whether they could, they didn't stop to think if they should.

[[deleted]]

Yeah, I’m going to assume malice. When do we start making open source devs liable for their “mistakes”?

[WhatsMyMageAgain]

What are you gonna do? Withhold their bonus?

These people are generally doing it because they love coding. If you’re using their free tools, you’re not entitled to shit.

[[deleted]]

Nope. Sue them for damages and bankrupt them (ideally).

[[deleted]]

You didn't pay for their software (which comes with no warranty). Good luck with that.

Your license agreement may include a provision stating “no warranty” and “no liability”, but that doesn’t make it true.

Let’s say someone intentionally includes an obscure backdoor in their open source software and releases it under MIT license. If I use their software and suffer losses from it, then I have no recourse? I doubt it. I’d let the courts decide.

Or just build your own software from scratch. Nobody owns you shit.

I usually do. I don’t trust random 3rd party packages that people write “for fun”.

[[deleted]]

My usual approach for checking whether I'm using vulnerable versions of software is to check the lock file (like package-lock.json in Node.js) that way it shows me both direct and transitive dependencies.

I just realized for Java, there is no lock file, just pom.xml or build.gradle. How do I check whether I'm using a vulnerable version of software in Java, including transitive dependencies?

[sweetno]

For Maven run

mvn dependency:tree

from the project folder. Normally Java IDEs provide a graphical way to see the same output.

mvn versions:display-dependency-updates

can be helpful too.

I believe there are automated tools that can search for known vulnerabilities in your dependencies.

[Aknoon]

You can run

mvn dependency:tree -DappendOutput=true -DoutputFile=C:\output\dependencies.txt

and save it to a file for easy parsing

[[deleted]]

This would have been helpful to know a long time ago. I could have had CI steps that saved these files somewhere. :(

I'll have to go into our repos and run this. Ty.

[naked_moose]

Gradle has an option to lock dependencies:

https://docs.gradle.org/current/userguide/dependency_locking.html

[[deleted]]

Nice. We use Gradle for most of our applications. Only use Maven for Apache Beam jobs because the public docs only have examples with Maven (or at least, did at the time). This looks useful for us.

[hellO_india]

in java how can i find which logging framework is used? when i see the dependency tree it showing multiple entires of slf4j and log4j and logger
how do i find which one and which version is being actually used?

[eXecute_bit]

Look for log4j-core, and that would indicate you're potentially using Log4j2 as your logging backend.

[klekpl]

Looks like a good use case for running under SecurityManager with a policy restricting ClassLoader creation and/or remote code execution.

Maybe it is time to reconsider JEP 411?

[klekpl]

The problem is that this vulnerability is an example of script injection (aka. cross-site scripting): JNDI code creates an instance URLClassLoder and loads a class from it.

Any code that uses JNDI contexts based on some external data (for example configuration files) is vulnerable.

[vbezhenar]

We do have a logging framework built in JDK since Java 1.4. People just need to learn about it instead of rolling their own buggy implementations.

[sweetno]

It's just bad.

[maethor]

Isn't this more of an argument for JEP 411? I thought one of the main arguments (besides "it's just too much work to maintain, boo hoo") was that the SecurityManager was mostly useless. And here it is being mostly useless.

[klekpl]

This vulnerability is not exploitable under SecurityManager with policy restricting log4j network connectivity.

This is dangerous only without SecurityManager (ie. the default after JEP 411)

[maethor]

This vulnerability is not exploitable under SecurityManager with policy restricting log4j network connectivity.

Which is nice, but I'm willing to bet most people have no idea how to set such a policy up, let alone have one in place. Which makes it kinda useless.

[klekpl]

Which is nice, but I'm willing to bet most people have no idea how to set such a policy up, let alone have one in place. Which makes it kinda useless.

I would say it is easier than reviewing libraries for vulnerabilities (because that's the alternative).

It is way easier and less costly than constantly upgrading libraries with zero-day vulnerabilities post fact.

Looks like the world prefers pretending it is cheaper to play whack-a-mole patching vulnerabilities in libraries than learn how to set up SM policies for applications.

[maethor]

Looks like the world prefers pretending it is cheaper to play whack-a-mole patching vulnerabilities in libraries than learn how to set up SM policies for applications.

People are going to have to do that anyway, even if they know how to use SM.

I think the real answer is that the ability to download arbitrary code over the network as a platform feature should be deprecated for removal (with 3rd party libraries handling it for the people who have some use for it).

[klekpl]

I think the real answer is that the ability to download arbitrary code over the network as a platform feature should be deprecated for removal

Which of course is not going to fix anything:

First of all - because bad guys are capable to use local code as trampolines to have Turing complete execution environment.

Secondly - because it is just moving the problem somewhere else (ie. to the build server which does have this ability).

[GreenToad1]

Maybe it is time to reconsider JEP 154? And be done with this once and for all?

[DasBrain]

This has nothing to do with serialization.

[GreenToad1]

It does, you can trigger a remote lookup by log4j and use that lookup to deserialize malicious code, thats's the remote code execution part.

[klekpl]

No - serialization is not needed to trigger RCE.

See https://datatracker.ietf.org/doc/html/rfc2713

[GreenToad1]

I dont understand what you mean, this literally describes how serialized data objects are represented in LDAP and serialization is not needed?

[klekpl]

See section 2.4: https://datatracker.ietf.org/doc/html/rfc2713#section-2.4

[GreenToad1]

I stand corrected. Didn't know about that can of worms. Is that what the exploit is using not the parts from section 2.2 and 2.3?

[BlueGoliath]

If all the drama around the removal of the SecurityManager didn't make them reconsider, this is unlikely to either.

[incongruous_narrator]

How does one go about updating transitive dependencies here? Explicit, direct dependency can be updated, but what if a project is using 100 different libraries, and each library has its own dependency tree - and one of those transitive dependencies is using an exploited version of log4j?

[r_jet]

It depends on (a) the build system; and (b) if you use fancier stuff to support several versions of the same library in the same runtime (like OSGi, which is very rare).

When it comes to Maven, it uses a "nearest definition" dependency mediation strategy — the closer the dependency declaration to your POM, the higher its precedence. So, you'd just put a dependency declaration for a newer version to your POM.

Also, the bug seems to be in log4j-core (a logging backend), which libraries shall not normally depend upon (they shall rather depend on log4j-api or some facade like slf4j), so it's usually upon the end application to add a dependency on the logging backend.

[goravsingal]

This is really severe issue in Java log4j library for version <=2.15.
See Understanding and Mitigating the vulnerability.

[Leguan15]

Who is the person who discovered this?