A critical flaw in the H2 open-source Java SQL database is similar to the Log4J vulnerability, but do not pose a widespread threat.
Researchers discovered a bug related to the Log4J logging library vulnerability, which in this case opens the door for an adversary to execute remote code on vulnerable systems. However, this flaw does not pose the same risk as the previously identified in Log4Shell, they explained.
Rated Critical
JFrog security found the flaw & rated critical in the context of the H2 Java database console, a popular open-source database, according to a Thurs. blog post by researchers.
H2 is favoured by developers for its lightweight in-memory solution–which precludes the requirement for data to be stored on disk & is used in web platforms such as Spring Boot & IoT platforms such as Thing Works.
Log4Shell
However, the flaw (CVE-2021-42392) is similar to Log4Shell. “It should not be as widespread” due to a few conditions & factors, JFrog researchers Andrey Polkovnychenko & Shachar Menashe wrote in their post.
Log4Shell (CVE-2021-44228) was tied to the Apache Log4j logging library in early Dec. & immediately exploited by attackers. It created 60 variants of the original exploit created for the defect in a 24-hour period as well as a faulty fix that could cause DoS attacks when it was 1st released.
How is the H2 Bug Similar to Log4J?
The ultimate cause of the H2 flaw is based in JNDI remote class loading, making it similar to Log4Shell in that it allows several code paths in the H2 database framework pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function.
This allows for remote codebase loading, also known as Java code injection or remote code execution, researchers stated.
“Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name & database URL as parameters,” they explained.
“If the driver’s class is assignable to the javax.naming.Context class, the method instantiates an object from it & calls its lookup method.”
Reasons to Be Careful
However, unlike Log4Shell, the H2 flaw has a “direct” scope of impact, meaning that typically the server that processes the initial request—that is, the H2 console—will feel the direct brunt of the remote code execution (RCE) bug, researchers wrote in a post published Thurs.
“This is less severe compared to Log4Shell since the vulnerable servers should be easier to find,” researchers wrote.
Secondly, by default on normal distributions of the H2 database, the H2 console only listens to localhost connections, thus making the default setting safe, they noted.
Exploitable
“This is unlike Log4Shell which was exploitable in the default configuration of Log4j,” researchers wrote. However, the H2 console can easily be modified to listen to remote connections as well, which would widen the risk, researchers added.
This aspect definitely weakens its severity in comparison to the Log4j issue, noted one security professional.
“Log4j was unique in that any number of attack-manipulated strings, from headers to URL paths, could result in exploitation of the victim depending on how the application was set up to utilise logging with Log4j,”
Changing the Configuration
Matthew Warner, CTO & Co-Founder at automated threat detection & response technology provider Blumira, wrote: “In this case, the H2 database console must be purposefully exposed to the internet by changing the configuration.”
Thirdly, while many vendors may be running the H2 database, they may not run the H2 console with it, JFrog researchers observed. There are other attack methods that can use the H2 flaw; however, they are “context-dependent & less likely to be exposed to remote attackers,” researchers observed.
Who Is At Risk?
If the H2 flaw does not deserve the same alarm as Log4Shell, why is it worth noting, one may ask. The JFrog team said that it can be extremely critical & allow for unauthenticated RCE to those running an H2 console exposed to a local area network (LAN) or, even worse, a wide area network (WAN).
Also, attacking the H2 console directly is the most severe attack pattern, researchers commented.
Blumira’s Warner explained that according to open-source intelligence (OSINT), there are likely under 100 servers on the internet affected by the H2 flaw, “so only a very limited number of organisations” are directly affected, he outlined.
Sensitive Services
“This vulnerability is a good reminder that it is important to ensure that sensitive services are only internally exposed to mitigate potential future risks,” Warner added.
Also, JFrog researchers stated that many developer tools rely on the H2 database & specifically expose the H2 console. This is problematic due to the “recent trend of supply chain attacks targeting developers, such as malicious packages in popular repositories.”
These attacks emphasise “the importance of developer tools being made secure for all reasonable use cases,” researchers wrote, which is why they hope many H2-dependent tools will be safer after applying their recommended fix.
Upgrade
So, the JFrog team recommends that all users of the H2 database upgrade to version 2.0.206, which fixes CVE-2021-42392 by limiting JNDI URLs to use the local java protocol only, denying any remote LDAP/RMI queries, researchers explained.
“This is similar to the fix applied in Log4j 2.17.0,” they wrote.
Those not directly using the H2 console should update too “due to the fact that other attack vectors exist, & their exploitability may be difficult to ascertain,” researchers concluded.
