OP 19 December, 2021 - 12:57 PM
The first patch did not fully address the Log4Shell vulnerability
Apache last week released version 2.15 of its Log4j logging utility, designed to address the notorious Log4Shell vulnerability ( CVE-2021-44228 ), which allows hacking of Java-based servers and applications over the Internet.
However, this update only partially fixed the vulnerability. In version 2.15, only one aspect of JNDI's message retrieval functionality was disabled by default. Now a second fix, 2.16, has been released, disabling all JNDI support by default and completely removing message lookup handling.
The release of the second update was necessary because version 2.15 can still be exploited under certain non-factory configurations. This issue has been assigned its own identifier CVE-2021-45046 .
Apache acknowledged that JNDI "has serious security issues," so the decision was made to disable it by default.
“CVE-2021-44228 showed us that JNDI has serious security issues. Although we eliminated what we knew, it was decided to completely disable it by default for greater user safety, especially since most people hardly use it at all, ” Apache said .
Therefore, in version 2.16.0 JNDI is disabled. JNDI is an API used by Log4j to retrieve objects from remote servers for use in log records.
With JNDI enabled, attackers can force the Log4j utility to extract Java code from a server under their control and execute it, compromising the device. To do this, attackers must enter specially crafted text, for example, in the name of an application account or in a search query on a site. When logged by Log4j, this will trigger remote code execution.
The Java Naming and Directory Interface (JNDI) is a set of Java APIs organized as a directory service that allows Java clients to open and view data and objects by name. Like any other Java API, like a set of interfaces, JNDI is independent of the underlying implementation. In addition to this, it provides a service provider interface (SPI) implementation that allows directory services to be paired with a framework.
Source : https://www.securitylab.ru/news/527611.php
Apache last week released version 2.15 of its Log4j logging utility, designed to address the notorious Log4Shell vulnerability ( CVE-2021-44228 ), which allows hacking of Java-based servers and applications over the Internet.
However, this update only partially fixed the vulnerability. In version 2.15, only one aspect of JNDI's message retrieval functionality was disabled by default. Now a second fix, 2.16, has been released, disabling all JNDI support by default and completely removing message lookup handling.
The release of the second update was necessary because version 2.15 can still be exploited under certain non-factory configurations. This issue has been assigned its own identifier CVE-2021-45046 .
Apache acknowledged that JNDI "has serious security issues," so the decision was made to disable it by default.
“CVE-2021-44228 showed us that JNDI has serious security issues. Although we eliminated what we knew, it was decided to completely disable it by default for greater user safety, especially since most people hardly use it at all, ” Apache said .
Therefore, in version 2.16.0 JNDI is disabled. JNDI is an API used by Log4j to retrieve objects from remote servers for use in log records.
With JNDI enabled, attackers can force the Log4j utility to extract Java code from a server under their control and execute it, compromising the device. To do this, attackers must enter specially crafted text, for example, in the name of an application account or in a search query on a site. When logged by Log4j, this will trigger remote code execution.
The Java Naming and Directory Interface (JNDI) is a set of Java APIs organized as a directory service that allows Java clients to open and view data and objects by name. Like any other Java API, like a set of interfaces, JNDI is independent of the underlying implementation. In addition to this, it provides a service provider interface (SPI) implementation that allows directory services to be paired with a framework.
Source : https://www.securitylab.ru/news/527611.php
