We interrupt your usual programming to bring you this breaking news about CVE-2021-44228, a.k.a “Log4Shell” vulnerability.
However, there is not much to talk about. MidPoint is not vulnerable to this attack, as midPoint is not using the Log4j logging implementation.
Despite that, there are some thoughts that we would like to share concerning this dangerous and far-reaching vulnerability.
First of all, let’s talk about midPoint and Log4j. MidPoint is not vulnerable, as it is using Logback instead of Log4j for its logging. There is an Log4j API code in midPoint, mostly to redirect logging of libraries that were built for Log4j logging to Logback. However, Log4j API is not vulnerable to the Log4Shell attack, only Log4j implementation (log4j-core) is, and the implementation is not part of midPoint. Therefore midPoint is safe. We will be upgrading Log4j API to the non-vulnerable version, just to be on the safe side. This is mostly a precaution to avoid dragging in vulnerable Log4j implementation to midPoint by mistake some time in the future. However, as far as we know, all supported midPoint versions are safe from Log4Shell attack and no special action is needed to patch them.
However, there is a deep concern behind this vulnerability. It is a zero-day remote code execution vulnerability in a popular library, which makes it extremely dangerous. This is not the first such vulnerability. This is all too familiar for those of us who lived through Heartbleed. There is one more thing that Log4J and OpenSSL have in common: they are popular open source projects maintained by a handful of volunteers.
This is yet another reminder of the open source funding problem. Log4j developers are not to be blamed for this bug. It is not in the powers of small group of volunteers to maintain the code, review all the contributions, realize all the consequences, test all the cases. Software maintenance is a very demanding job, requiring constant attention. Yet, the developers are not paid by Log4j users. It is no wonder that they cannot find the time to do long-term maintenance of the library. Log4j project is not alone. Many popular open source projects are desperately underfunded (read as “not funded at all”). This puts all of us in danger, including the commercial closed-source software products that routinely rely on open source libraries. In a way, all of us are affected by this vulnerability.
This is neither the first nor the last such vulnerability. Software needs to be looked after, which takes time and requires money. We have found a way to fund the development and maintenance of midPoint, which is an open source application. However, the same model is not applicable for open source libraries. We are contributing to the development and maintenance of libraries that we use in midPoint, such as ConnId connector framework or Apache Directory API. However, this is only very small fraction of open source infrastructure that forms a foundation of the entire IT world. Many of the popular libraries are under-funded and under-maintained. Therefore, there will be more Heartbleeds and Log4Shells in the future. That is quite clear.
What to do about it? There is no clear answer. This is a tragedy of the commons, the open source funding problem is still unsolved. However, the least that you can do is make sure you send some money to the open source software you use. Many open source developers offer support services, make sure you use these. Even donations can help, although they do not provide steady income which is required for long-term maintenance. Do anything you can to make sure open source developers have funds that enable them maintaining their software. The future of IT industry depends on it.