...
- 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.
- LDAP is an example of one such standard. It is defined at the IETF. It's original use was for things like phone books and organization charts.
- 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.
- The Apache Software Foundation is an example of an open source organization. Companies and invited experts collaborate there to produce releases of software components and products. Along the way, those companies and individuals contribute their intellectual property to make this happen. Those releases are then incorporated into commercial and other open source products.
- 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. As Log4J is written in Java, 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 There have been prior efforts to list identify critical functions, yet somehow 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 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.
- The handling of the issues in log4j followed ASF processes and the fixes were timely.
...