A critical remote code-execution (RCE) bug in an open source Java virtual machine (JVM) framework threatens enterprise environments by giving attackers an easy way to compromise development teams — thus gaining access to production systems.
That’s according to Joseph Beeton, senior application security researcher at Contrast Security, who discovered the vulnerability in Quarkus, a Red Hat-managed, Kubernetes-native Java framework that’s optimized for JVMs.
The bug is tracked as CVE-2022-4116 and has been given a rating of 9.8 on the CVSS.
The relatively new Quarkus framework is used as a platform for serverless, cloud, and Kubernetes environments — the last of which is the de facto container-management platform for cloud-native environments, and has had numerous security issues of its own.
The Quarkus flaw is present in the framework’s Dev UI Config Editor, making it vulnerable to drive-by localhost attacks that could lead to RCE, Beeton wrote in a blog post published Nov. 29. Moreover, “exploiting the vulnerability isn’t difficult, and can be done by a malicious actor without any privileges,” he noted in the post.
Beeton discovered the vulnerability some weeks ago while preparing a talk for the recently held DeepSec conference, but says that he waited to disclose his findings until after Red Hat published details
of the flaw on its customer support portal Nov. 21. Beeton also published a proof of concept exploit for CVE-2022-4116 in his post.
Patched versions of Quarkus, available now, are 2.14.2.Final and 2.13.5.Final (LTS); anyone using the framework is encouraged to update immediately.
‘Dangerous’ Security Flaw
The vulnerability affects the “quarkus_dev_ui” package, according to Red Hat, which means it impacts developers building services using Quarkus, not actual services running in production.
However, it’s still dangerous for several reasons — for one because it’s fairly easy to exploit, and for another because developers often have direct access to an enterprise’s production environment, Beeton told Dark Reading.
“Developers generally have access to production systems, and even if they don’t, they do have the ability to make code changes,” he says. “A compromised developer’s machine could be leveraged to push malicious code changes to production.”
In enterprise cloud-based environments, developers also often have to code bases, Amazon Web Services keys, server credentials, and other assets, Beeton said in his posting.
“Access to the developer’s machine gives an attacker a great deal of scope to pivot to other resources on the network, as well as to modify or to flat-out steal the codebase,” he wrote.
The Bug in a Cloud-Security Context
The flaw must be understood in the context of cloud-based footprints that have numerous hosted services running in a larger environment, Beeton explained. One misconception about this type of architecture is that “services that are only bound to localhost are not accessible from the outside world,” he noted in his post.
“Because of this misplaced belief, developers, for the sake of convenience, will run services they are developing that are configured in a less secure way compared with how they would [typically] do it,” he wrote.
However, in the case of a certain type of request that does not require a preflight request — called Simple Requests — the flaw comes into play, Beeton said.
Multiple Ways Developers Can Be Targeted
In this way, attackers can access developer code via non preflighted HTTP requests to those services bound to localhost, he explained.
“It just requires that Quarkus is running in developer mode at the same point the browser tab is open,” he noted. “No other interaction is required for this vulnerability to be exploited.”
Other ways the flaw can be exploited are through common misconfigurations in the Spring framework, which provides a comprehensive programming and configuration model for modern Java-based enterprise applications, he said. Alternatively, an attacker can exploit known vulnerabilities to generate an RCE on the developer’s machine or on other services on their private network.
Potential Impact and Fix
The other reassuring aspect is that Quarkus is a young framework, having been launched in 2019, so it’s not likely to be used as extensively as, say, the open-source Spring Boot framework, he said.
And while Quarkus is gaining in popularity, particularly for Kubernetes
enthusiasts, “given its ease of use and significantly lighter demand on hardware resources to run and to run applications,” it still is not as widely used as Kubernetes itself, Beeton said.
“Therefore, the number of developers affected by this drive-by localhost attack is probably small,” he said.
Squashing the Attack Vector
Even with the Quarkus flaw fixed, developers using open-source frameworks still should be wary as they develop services via the localhost, as there are likely more vulnerabilities equivalent to CVE-2022-4116 that have yet to be found, Beeton warned.
A solution for the entire attack vector is on the horizon with W3C’s new Private Network Access (PNA) specification, which eventually will be integrated into browsers to squash this mode of exploit altogether, he said.
Currently, however, only the team supporting the Chromium framework — the basis for the Chrome and Edge browsers — is actively working to implement the new spec, Beeton said. In fact, the targeted mid-December release of Chrome 109 should include support for PNA.
Firefox, meanwhile, has PNA support on its backlog, but has not yet scheduled a release date, while plans to add the spec to Safari or Edge remain unclear, though the Chromium update may bode well for its upcoming addition in Edge, he added.