“We build our computers the way we build our cities — over time, without a plan, on top of ruins.”
― Ellen Ullman
This is one of my favorite quotes when it comes to describing the general security level of all our IT systems. It applies even more to the Apache Log4j disaster, which half the world is currently dealing with, while admins are panicking and dropping everything to patch systems. We should be clear with ourselves that such horror scenarios will continue to happen in the future, and above all, more frequently. This is mainly due to the increasing complexity of IT systems and the way software is developed and infrastructures are built today, namely: over time, without a plan, on top of ruins.
If we look at “state-of-the-art” software projects, we will see that they do not hold back when it comes to dependencies on third-party libraries. This is especially bad in web applications, where you can quickly pull a mid-two-digit number of dependencies into the codebase, developed by various people and maintained to varying degrees. Since these third-party libraries often follow hobbyist or semi-professional approaches, as a user you cannot expect that the computer scientist who hacked together a NodeJS parser for Excel files after work will regularly maintain the project and its code, monitor the bug tracker, and review pull requests.
At the moment, we see numerous vendors checking their complex software products for exposure to the Log4j vulnerability. The mere fact that you first have to check your codebase and only then determine whether the library is even in use or which version is shipped says a lot about vendors’ quality processes.
During penetration tests, we unfortunately identify this issue on a regular basis. Reports often say: “Remote code execution due to outdated and vulnerable library X” or “Cross-site scripting due to outdated and vulnerable library Y”.
What do we learn from this?
Vulnerabilities inevitably arise when humans develop software; that is unavoidable and okay. But for our IT systems, we need much less complexity and much more clarity about how they actually work. That leads to simpler and faster action when it truly matters.
A comment by Jens Regel.