Researchers discover Log4j-like flaw in H2 database console

Impact of JNDI bug mitigated by vulnerable behavior being disabled by default

A vulnerability with the same root cause as the notorious Log4j flaw has been patched in the console of the hugely popular Java SQL database, H2 Database Engine.

As with the recent ‘Log4Shell’ exploits, unauthenticated attackers can achieve remote code execution (RCE) because the console accepts arbitrary Java Naming and Directory Interface (JNDI) lookup URLs.

The flaw (CVE-2021-42392) “allows loading of custom classes from remote servers through JNDI”, as per a GitHub security advisory published by the H2 maintainers on January 5.

RECOMMENDED Researcher discovers 70 web cache poisoning vulnerabilities, nets $40k in bug bounty rewards

The vulnerability vindicated the suspicions of the security researchers who found it – that the widespread usage of JNDI suggested “there are bound to be more packages that are affected by the same root cause as Log4Shell”, according to a blog post published yesterday (January 6) by Andrey Polkovnychenko and Shachar Menashe of cybersecurity firm JFrog.

With almost 7,000 artifact dependencies, H2 is one of the most popular open source Maven packages.

Worryingly, given “the recent trend of supply chain attacks targeting developers”, Polkovnychenko and Menashe said they’d observed many H2-dependent developer tools exposing the H2 console.

Secure by default

The pair described the flaw as “extremely critical” if H2 consoles are exposed to a LAN, or worse, WAN.

However, the threat is considerably reduced by the fact that the H2 console is safe in its default setting, only listening to localhost connections (although it is simple to enable remote connections, the researchers note).

Moreover, the RCE will typically only impact the server that processes the initial request, and many vendors running the H2 database may not be exposing the H2 console.

Nevertheless, JFrog recommends that all H2 users upgrade to the latest version whether they directly use the H2 console or not.

This is because other attack vectors exist – the researchers also found H2 Shell tool and authentication-dependent SQL vectors – albeit they are “context-dependent and less likely to be exposed to remote attackers”.

Limiting JNDI URLs

Vulnerable H2 versions span 1.1.100 to 2.0.204 inclusive.

The researchers praised the H2 maintainers for addressing the flaw promptly in version 2.0.206, released on January 5.

Similar to the Log4j fix, the patch limits JNDI URLs to using the local Java protocol only, thus blocking remote LDAP/RMI queries.

Catch up on the latest Log4J vulnerability news and analysis

Regardless of patching “ is a dangerous setting that should be avoided”, warns the H2 advisory.

But if the H2 console Servlet is deployed on a web server, users can add a security constraint that will allow only specific users access to the console page.

“To the best of our knowledge, CVE-2021-42392 is the first JNDI-related unauthenticated RCE vulnerability to be published since Log4Shell, but we suspect it won’t be the last,” said Polkovnychenko and Menashe.

As such, JFrog is continuing to probe for similar flaws.

JNDI injection was, incidentally, leveraged prior to Log4Shell by Taiwanese researcher Orange Tsai who compromised internal Facebook systems in 2020 via a vulnerability in mobile device management platform MobileIron.

YOU MIGHT ALSO LIKE Java RMI services often vulnerable to SSRF attacks – research