How to Fix CVE-2022-4116- A 0-Day Vulnerability in Quarkus Java Framework

Joseph Beeton, a security researcher from Contrast Security, has disclosed a 0-day vulnerability in the Quarkus Java framework. The flaw, which is tracking as CVE-2022-4116, got a score of 9.8 on the CVSS scale and is considered critical in severity. As per the security researcher, the flaw exists only in the development version of the framework, which allows attackers to silently execute code on the victim’s machine running developer release of Quarkus’s User Interface and a malicious JavaScript simultaneously on the same browser. Considering its severity and implications, we published this post that help you learn how to fix CVE-2022-4116, a 0-day vulnerability in Quarkus Java Framework.

Before we go ahead and see how to fix CVE-2022-4116, let’s see a short note about Quarkus Java Framework and its development environment because it is a must to learn about the development environment preflight request and JavaScript to understand the flaw. Please, don’t skip the below section where we tried to explain them. If you are interested only in learning how to fix the flaw, then you may skip these sections and directly jump into the final section.

A Short Note About Quarkus Java Framework

Quarkus is an open-source Java framework designed to be a Kubernetes-native, cloud-native, and developer productivity-focused application platform. It builds upon the familiar technologies of the Java ecosystem, such as Eclipse Microprofile and Apache Tomcat, to enable developers to create applications that have excellent performance characteristics while being more productive than ever before. Quarkus also uses GraalVM for its Ahead of Time (AOT) compilation capabilities which allows for extremely fast startup times, reducing both development cycle time and operational expenditure.

Quarkus dev Mode:

Quarkus has a development mode with dev UI that allows developers to rapidly develop, build, deploy, and debug their applications in a fast-iterative cycle. By leveraging live coding techniques, changes made during development are instantly reflected in the running application without having to manually recompile it every time. This makes it much easier for developers to experiment quickly with different ideas and features. Additionally, Quarkus Dev Mode provides an enhanced debugging experience for developers. By running their applications in the same JVM as their IDE, breakpoints can be set and variables monitored from within the IDE itself – making it easier to quickly identify and fix issues.

Quarkus dev mode has some security caveats. To make the development version more flexible than the production version and considering development mode is safe from internet attackers as the dev mode is designed to run only on the developer’s machine and bound to localhost, some security features like Cross-Site Request Forgery (CSRF) token, authentication and/or other security controls were skipped by design. It is allowed to modify the properties just by sending a POST request with the content type of application/x-www-form-urlencoded. 

Summary of CVE-2022-4116

This is a critical severity vulnerability with a CVSS score of 9.8 out of 10. The flaw actually lies in the User Interface of the development release of the framework. The flaw allows attackers to carry out remote code execution attacks on the victim machine running Dev UI and malicious JavaScript at the same time on the same browser.

What is a Preflight Request?

A preflight request is an HTTP request sent to a server from the browser before a Cross Origin Resource Sharing (CORS) request is made. It enables browsers to securely determine whether or not to perform the actual request by providing servers with information about what kind of operation and data will be requested.

Preflight requests are a part of CORS, and they help prevent malicious or accidental data loss. A preflight request will typically issue an HTTP OPTIONS request header to the server, which contains methods, headers, and other information that is used by the browser to determine if the actual request should be made.

If the response from the server indicates that the actual request can be made safely, then the browser will continue with the request. Without preflight requests, an attacker can make malicious or accidental requests that could potentially cause data loss or other harm. Preflight requests are a crucial part of making cross-origin requests secure and reliable.

The preflight request is usually sent ahead of the actual request, but it may also be sent at the same time as the actual request. Additionally, some browsers are capable of caching preflight requests and their associated responses so that they don’t have to be sent every time a cross-origin resource is requested. This can improve performance in certain scenarios where the same cross-origin requests are being made multiple times.

Overall, preflight requests are an important part of securely making cross-origin requests, and they can help protect against data loss and other malicious activities. They should always be used when making cross-origin requests in order to ensure the safety of users’ data.

Where Does the Flaw Exist?

JavaScripts are designed to make requests only to the domain from where the script is originally downloaded. They are not allowed to make a request to other domains, including the localhost (request to the same host on which the script is running). If JavaScript is needed to make a request to the different domain only through the preflight requests.

“By compromising websites used by developers — for example, by simply injecting JavaScript into advertisements served on those sites or by launching a phishing attack that gets the developer to open a web browser on a compromised page — it is possible to reach out via non-pre-flighted HTTP requests to those services bound to localhost. It can be done by exploiting common misconfigurations in the Spring framework.”
– By Joseph Beeton, Senior Application Security Researcher, Contrast Security

This Spring framework flaw lets an attacker carry out remote code execution attacks on the victim machine running Dev UI and malicious JavaScript at the same time on the same browser. This attack doesn’t need manual interaction to exploit the vulnerability. It just needs someone who is running Quarkus in developer mode to go to a website containing the malicious JavaScript, as the JavaScript can be executed on page load by continually attempting to hit localhost or both. 

How to Fix CVE-2022-4116- A 0-Day Vulnerability in Quarkus Java Framework?

RedHat fixed the flaw in 2.14.2.Final or 2.13.5.Final. We recommend upgrading Quarkus Java Framework to one of these versions to fix the 0-Day vulnerability in Quarkus Java Framework. If you are not in a position to upgrade anytime soon, there is a workaround.

Use a random path for the Quarkus Dev UI by moving all the non-application endpoints to a random root.

%dev.quarkus.http.non-application-root-path=<your random string>

The Dev UI is then available at the following URL: http://localhost:8080/<your random string>/dev/.

We hope this article helped in understanding how to fix CVE-2022-4116, a 0-day vulnerability in Quarkus Java Framework. Please share this post and help to secure the digital world. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram, and subscribe to receive updates like this.