The CVE-2023-4853 vulnerability in question impacts Quarkus framework’s HTTP Security Policy, . This policy provides access control to various endpoints within an application enabling developers to secure access based on path-based configurations. However, a critical flaw has been identified in how the HTTP Security Policy handles request paths containing multiple adjacent forward-slash characters.
Issue Summary
Quarkus provides several methods to secure HTTP endpoints. The HTTP security policy, provides secured access through a path-based configuration. However, it does not correctly handle request paths containing multiple adjacent forward-slash characters.
For example (application.properties):
quarkus.http.auth.permission.role-admin.paths=/secured/*
In this example, you can bypass the security policy by including an extra pair of slash before the security path. For example:
Besides, please note that this issue also affects HTTP secured resources via web.xml. For example:
<security-constraint>
<web-resource-collection>
<web-resource-name>example</web-resource-name>
<url-pattern>/secured/*</url-pattern>
<url-pattern>/openapi/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
Versions Affected:
This issues affects several branches of Quarkus such as versions 2.16, 3.2 and 3.3 of Quarkus.
Resolution
Download one of the following updates available in Quarkus 2.16.11.Final, 3.2.6.Final, and 3.3.3 . If you are using Red Hat build of Quarkus, then use the 2.13.18.SP2 as discussed in https://access.redhat.com/security/cve/cve-2023-4853
To align your code to the correct version, the simplest option is update your Maven or Gradle coordinates by setting one of these versions. For example:
<quarkus.platform.version>3.3.3</quarkus.platform.version>
Alternatively, for previous Quarkus versions, include the Final suffix in the version:
<quarkus.platform.version>2.16.11.Final</quarkus.platform.version>
On the other hand, if you cannot upgrade in the shortest term, you can mitigate the issue by adding a a wildcard ‘deny’ policy. This policy will ensure that all requests not covered by the existing policies are blocked.
For example:
deny: /* authenticated: /secured/*
Conclusion
In conclusion, it is strongly recommended that all users of Quarkus, especially those leveraging the HTTP Security Policy, take immediate action to address this vulnerability. Implementing one of the suggested mitigations, based on your application’s specific requirements and constraints, is a critical step toward maintaining the security and integrity of your systems.
Found the article helpful? if so please follow us on Socials
