Last week and this week I’ve been quite busy helping colleagues and clients of mine understand and fix a critical vulnerability in Log4J
. Even if you’re not a Java developer, you’ve probably heard of the story by now 😂.
That’s the fun part about my part-time job; it’s really varied. I get to work on software development, software frameworks, troubleshooting problems, PaaS, IaaS, DevSecOps, RFPs, IT security, etc.
This vulnerability is really a monstrous one. Very easy to exploit, and incredibly impactful. Basically, if you attack a vulnerable host and can inject a string into the logs, then it’s game over, you own the machine. Ouch! You can learn more about it here
, and here
Soon after the main vulnerability was announced, additional ones were uncovered and reported. Not a huge surprise given the fact that all eyes turned towards that codebase.
I’m saddened to have read so many negative comments about Log4J and the team behind it all around the Web. It’s the way of the Internet, but the team behind this Open Source project really doesn’t deserve this. I wouldn’t like to be in their shoes right now. Open Source work is mostly thankless, unfortunately…
People only care about today’s RCE and forget about everything that Log4J has done for the ecosystem and all the time the maintainers have given away for the community. Log4J has been a great addition to the Java ecosystem many years ago and has served us well. When Ceki
created it (20 years ago!), we were stuck with limited and clunky JDK APIs. Log4J 1 introduced configurable loggers, configurable logging patterns, and many other much-needed innovations. No wonder that this library became so popular and so present all around the place. It actually influenced libraries in other programming languages.
What’s interesting to me is that this vulnerability has been introduced because the library maintainers tried to please too many people. Or at least that’s my understanding.
Yes, it is nice to have a way to dynamically fetch information from the environment through JNDI and other means, but is it actually a must? No, absolutely not. That information could be fetched in various ways without extending the logging library.
To me, it is obvious that for some things in life, less is more
. Low-level tools and libraries need to do one thing only and do it well (i.e., the Unix philosophy
). Whatever’s going a tad too far should actually live elsewhere in the software stack.
This story highlights two points:
- The importance of being able (and willing) to reject feature requests and even ready-made Pull Requests in Open Source projects
- The importance of revisiting past choices and daring to introduce breaking changes in favor of a leaner and cleaner solution