[midPoint] Blog: MidPoint Not Vulnerable to Log4Shell

[Radovan Semancik]

Dear midPoint community,

We interrupt your usual programming to bring you this breaking news 
about CVE-2021-44228 <https://nvd.nist.gov/vuln/detail/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 sometime 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 project 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 is 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 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 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 to maintain their software. The future of IT 
industry depends on it.

(Reposted from Evolveum blog 
<https://evolveum.com/midpoint-not-vulnerable-to-log4shell/>)

-- 
Radovan Semancik
Software Architect
evolveum.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20211213/043ab219/attachment.htm>