Indeed, this aspect of the execution of the flaw definitely lessens its severity in comparison to the Log4j issue, noted one security professional. Still, the H2 console can easily be modified to listen to remote connections as well, which would widen the risk, researchers added. “This is unlike Log4Shell which was exploitable in the default configuration of Log4j,” researchers wrote. Secondly, by default on vanilla distributions of the H2 database, the H2 console only listens to localhost connections, thus making the default setting safe, they noted. “This is less severe compared to Log4Shell since the vulnerable servers should be easier to find,” researchers wrote.
H2 database code#
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 Thursday. “If the driver’s class is assignable to the class, the method instantiates an object from it and calls its lookup method.” Reasons to Be Wary, but Not Panic
H2 database driver#
“Specifically, the org.h2. method takes a driver class name and database URL as parameters,” they explained in the post. This allows for remote codebase loading, also known as Java code injection or remote code execution, researchers said. The root 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 function. It spawned 60 variants of the original exploit created for the flaw in a 24-hour period as well as a faulty fix that could cause DoS attacks when it was first released. Log4Shell ( CVE-2021-44228) was tied to the Apache Log4j logging library in early December and immediately exploited by attackers. “t should not be as widespread” due to a few conditions and factors, JFrog researchers Andrey Polkovnychenko and Shachar Menashe wrote in their post.
However, the flaw ( CVE-2021-42392) is similar to Log4Shell.
H2 is attractive to developers for its lightweight in-memory solution–which precludes the requirement for data to be stored on disk-and is used in web platforms such as Spring Boot and IoT platforms such as ThingWorks. JFrog security discovered the flaw and rated critical in the context of the H2 Java database console, a popular open-source database, according to a Thursday blog post by researchers. However, this flaw does not pose the same risk as the previously identified in Log4Shell, they said. 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.
0 kommentar(er)
