JFrog discovers JNDI vulnerability in open source Java SQL database H2

Google Chrome: Gepatchte Schwachstelle zeigt potenzielle Gefahr von Zero Day-Exploits

Vulnerability

Unauthenticated RCE in the H2 database console

The security researchers at JFrog have recently uncovered a problem in the H2 database console for which a critical CVE has been assigned – CVE-2021-42392. This problem has the same cause as the recently announced Log4Shell vulnerability in Apache Log4j.

H2 is a widely used open source Java SQL database that provides a lightweight in-memory solution that does not require the data to be stored on disk. This makes them a popular data storage solution for various projects, from web platforms like Spring Boot to IoT platforms like ThingWorks. The package com.h2database:h2 is one of the 50 most popular Maven packages with almost 7000 artifact dependencies.

Although it is a critical issue with a similar cause, CVE-2021-42392 is not expected to be as widespread as Log4Shell (CVE-2021-44228). Unlike Log4Shell, this vulnerability has a “direct” scope of action. This means that, as a rule, the server that processes the first request (the H2 console) is the server that is affected by RCE. This is less serious compared to Log4Shell because the vulnerable servers should be easier to find.

Many providers run the H2 database, but not the H2 console. Although there are other vectors besides the console to take advantage of this problem, these other vectors are contextual and less likely to be accessible to remote attackers. However, if you are running an H2 console that is accessible on the LAN, this problem is extremely critical (unauthenticated code execution remotely) and requires an immediate update of the H2 database to version 2.0.206 (or higher).

The security researchers have also found that many developer tools rely on the H2 database and in particular disclose the H2 console. The recent trend towards supply chain attacks on developers, e.g. by malicious packages in popular repositories, underlines the importance of secure developer tools for all use cases. It is to be hoped that many H2-dependent developer tools will also become more secure after applying this fix.

One of the most important findings from the Log4Shell vulnerability incident was that due to the widespread use of JNDI, there are inevitably more packages affected by the same cause as Log4Shell – the acceptance of arbitrary JNDI lookup URLs. Therefore, the researchers at JFrog have adapted their automated vulnerability detection framework to include the javax function.naming.Context.lookup is considered a dangerous feature.

Root cause of the Vulnerability – JNDI-Remote Class Loading

In short, the root cause is similar to Log4Shell – several code paths in the H2 database framework direct unfiltered, attacker-controlled URLs to the javax function.naming.Context.lookup continues, which allows loading a remote code base (also known as Java Code Injection or Remote Code Execution).

Vulnerability assessment for CVE-2021-42392

Network administrators can scan their local subnets for open instances of the H2 console, all found servers are most likely vulnerable. As already mentioned, there are other attack options, but remote exploitation is much less likely. In any case, the H2 database should be updated.

Discovery of CVE-2021-42392

The problem can be discovered via a data flow analysis (DFA) when using the HttpServlet built into Java.doGet/doPost methods as a user input source (especially the first req argument) and the aforementioned javax.naming.Context.the lookup method (which performs JNDI lookup) can be defined as a dangerous function/sink.

What is the proposed solution for CVE-2021-42392?

The recommendation for all users of the H2 database is to upgrade to version 2.0.206, even if you are not directly using the H2 console. The reason for this is that there are other attack vectors, the exploitability of which may be difficult to determine. Version 2.0.206 fixes CVE-2021-42392 by restricting JNDI URLs to use only the (local) Java protocol, which will deny all remote LDAP/RMI queries. This is comparable to the correction made in Log4j 2.17.0.

Defusing CVE-2021-42392

The best solution for this vulnerability is to upgrade the H2 database. For providers who are currently unable to update H2, there is the following remedy:
Similar to the Log4Shell vulnerability, newer versions of Java include the trustURLCodebase mitigation, which does not allow remote codebases to be loaded unsuspectingly via JNDI. Vendors should update their Java version (JRE/JDK) to enable this mitigation. The research of the researchers at JFrog reveals the cause of the problem and based on this, the above-mentioned corrected version of the H2 database, 2.0.206, was created. It is even more important now to upgrade to a corrected version of H2, as some attackers may have seen the earlier discovery and have been using similar attack vectors for some time.

Conclusion

The urgent recommendation is to update the H2 database to the latest version to avoid possible exploitation of CVE-2021-42392. As far as is known, CVE-2021-42392 is the first JNDI-related unauthenticated RCE vulnerability that has been released since Log4Shell, but it probably won’t be the last.

Ready to see us in action:

More To Explore

IWanta.tech
Logo
Enable registration in settings - general
Have any project in mind?

Contact us:

small_c_popup.png