The security flaws on the Apache Log4Shell module look like they will not end anytime soon. The company has recently released a patch dubbed 2.15.0, which was incomplete to fix the problems. Then the 2.16.0 version was released, and it was thought to be safe because it was just cutting the flawed services of Log4j. Now, whole new flaws emerge.
The flaw which is fixed by Log4j 2.17.0
The denial-of-service vulnerability, which is tracked as CVE-2021-45046, was fixed by the 2.16.0 version of the Log4Shell, by disabling JNDI lookups. However, a new way to break the system emerged. This new flaw is tracked as CVE-2021-45105 and has a CVSS score of 7.5. The flaw enables attackers to use a string to crash the application.
The user has shared the details as “If a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash”. The string can be seen below:
${${::-${::-$${::-j}}}}The CVE-2021-45105 vulnerability is fixed by the Log4Shell 2.17.0 update.
The flaw which is not fixed by Log4j 2.17.0
The new flaw tracked as CVE-2021-4104, which only appears in Log4j 1.x versions, expands Log4j’s attack surface. With this new vulnerability, attackers can exploit the servers locally via JavaScript WebSocket connection by using other exposed Log4j devices. Security researchers stated that there is no proof of active exploitation. They also warned about the significant expansion of the attack surface caused by this.
The flaw only works in the applications using JMSAppender, which is not active by default. This flaw is not patched by Apache yet. However, updating all local development and internet-connected environments to Log4j 2.16.0 or 2.17.0 is said to be removing the risk of exploitation for this flaw.
Over 35,000 Java packages are affected by the flaw
Google Open Source Insights Team also shared the details of their research about this period. In the results of their research, 8% of the Maven Central repository, which roughly equals 35,000, have been found using flawed Log4j versions, adding that only around 7,000 of them have a direct dependency on it.
Related Stories
- CISA published an emergency directive for Log4j
- Google joining the war against Log4j exploits
- Hackers exploit Log4j to inject Monero miners, shifting from LDAP to RMI
- A third, new Apache Log4j vulnerability is discovered
- How to scan your server to detect Log4j (Log4Shell) vulnerability
- The Log4j flaw is patched but it is still vulnerable
- CISA published Log4j vulnerability guidance
- Zero-day Apache Log4j RCE vulnerability (Log4Shell) is being exploited