...
Before jumping directly into what positions we have at the ASF, it is worth describing the factors contributing to the recent log4j vulnerability, and basing our recommendations . Our recommendations are based on those experiences.
...
The IETF, W3C, and WHATWG are examples of standards organizations. Companies and invited experts collaborate there to produce specifications of standards, formats, and protocols. Along the way, those companies and individuals contribute their intellectual property to make this happen. Those standards are then implemented by commercial and open source products.
...
Java is a programming language, and OpenJDK is the open source implementation of that language. Java contains a component, named JNDI ,that implements LDAP as well as a number of other standards such as CORBA and RMI. Those other standards provide the ability to do things like remote code execution which was popular in the 1990s, but now isn't quite so important.
...
Log4J is one such example of a software component produced by the ASF. It does the mundane job of producing an audit trail of important activities. Augmenting the audit trail with organization data from LDAP seemed like a good idea at the time, and as . As Log4J is written in Java, JNDI is a convenient way it made use of JNDI to access that data.
Put together, and you have a mundane and almost invisible function which can be tricked into doing remote code execution. Despite prior efforts to list critical functions, log4j never ranked high on any list. Furthermore, this vulnerability was not a bug (like a buffer overflow), but a combination of intentionally designed features when put together can be exploited. This went unnoticed for many years.
Since the vulnerability was disclosed, we had a number of inquiries from people trying to figure determine out if they were affected by this vulnerability. It turns out many were running log4j version 1, which was discontinued in 2015. The good news is that this particular vulnerability does not affect them. The bad news is that the code they are running has not benefited from any security fixes in many years.
...
- We support the notion of identifying critical components, even though that process is always going to be incomplete and imperfect. As our software is free without cost and can be downloaded by anybody, we have no way of knowing how widely our projects are used. This means that by necessity this must determining if a component is critical can only either be determined either by indirect means such as download counts, or by identifying critical products first, and then getting an inventory of what components those products embed.
- We eagerly accept and welcome audits and fixes from any source. We have a process defined for doing so: https://www.apache.org/security/. Our one caution is that we have prior experiences with audits and it is not productive when those audits produce a number of false positives. See https://s.apache.org/fhoji. It is worth noting that many automated means of performing an audit are more suited to detecting bugs inside a single component rather than identifying a vulnerability that is composed of combination of intentional features such as the one we saw with log4j.
- The problem of not knowing where our releases are being used needs to be fixed. This problem is not unique to the ASF, so it makes sense for there to be industry standards and best practices. We are prepared to participate in these activities.
- It is particularly frustrating to us that we can produces fixes in a matter of days or weeks and not to have those fixes be picked up for months or years. This is the problem that we see as most pressing.
...