Hands up who has heard of Log4Shell?  No? If you’re a Java developer and this term isn’t familiar to you then you might want to google it right now. We’ll wait.

The severity and impact of this vulnerability are so high that it’s easy to miss the fact that what makes this vulnerability deadly is not Log4J2, not JNDI, RMI, or LDAP, it’s good old fashioned Java serialization.  What those other technologies have done collectively is to make it trivially easy to exploit Java serialization weaknesses.  

Fixing Log4J2 closes a door but doesn’t address the fundamental challenge.  

Here’s an analogy:  

Imagine that a bank created a chatbot.  This chatbot was a great success, helping customers quickly resolve their queries. However, it was discovered that this chatbot would do whatever it was asked.  Suddenly users were exploiting the chatbot to steal money from other accounts, clear their overdraft, etc. The bank quickly fixes the problem by removing the flexibility in the chatbot so it can now only do a few restricted things.

What’s missed is that the chatbot was the front end.  In the background was a service that actually did the work. It’s still there, happy to do whatever it’s told.  Shutting down the chatbot closes down one route, but doesn’t remove the underlying cause.

What this series is about

Log4Shell is a vulnerability that obviously had to be addressed but it’s only one route.  There will always be others while the Java serialization design remains flawed.   

Many have asked why Java serialization continues to be available.  This is a good question. 

As we’ll explain, having serialization capability is a necessity for Java applications and the native implementation is so highly performant and easy to use that it (Read more...)