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.”
For example, if a developer running Quarkus locally visits a website with malicious JavaScript, that JavaScript can silently execute code on the developer’s machine, which can lead to all kinds of trouble on any network or assets attached to it.
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.
There’s no problem with this scenario in the case of accessing normal JavaScript in a browser and loaded from a nonmalicious domain, he said. In that case, the JavaScript would not be able to make requests to other domains, including localhost, without a preflight request that is used to check the server’s Cross-Origin Resource Sharing (CORS) settings. This is a standard check to see if the server allows requests from the domain being accessed.
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.
“For a Simple Request, the browser makes the request, receives the response, but that data — including the HTTP Status Code — is not returned to JavaScript,” he wrote. “It is possible, however, to infer whether the request was successful based on how long it took to return. Within those constraints, it is possible to access localhost and, in certain circumstances, to trigger arbitrary code execution.”
Multiple Ways Developers Can Be Targeted
If this is the case, threat actors can compromise websites that developers use by injecting malicious JavaScript into ads served on the sites. For an attack on the Quarkus flaw to be successful in this scenario, someone who is running Quarkus in developer mode would have to visit a website containing the malicious JavaScript, Beeton said.
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.”
Attackers also can exploit the flaw by launching a phishing attack that convinces a developer to open a web browser on a compromised page. “If they happen to be running Quarkus in developer mode, compromising them would merely entail getting them to click the link; the page containing malicious JavaScript will then be loaded, and they would be compromised,” Beeton explained.
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
There are two bits of good news surrounding the status of the flaw, Beeton acknowledged. One is that Red Hat’s Quarkus team, as mentioned before, already has issued a fix that requires the Dev UI to check origin headers for “origin : localhost” — which is set by the browser itself and not modifiable by JavaScript — and only accept these requests, he said.
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.
