RHSB-2023-002 Quarkus Security Policy Bypass - Quarkus - (CVE-2023-4853)

Executive summary

Red Hat is aware of a vulnerability in Quarkus endpoints utilizing the HTTP Security Policy, which could allow an unauthenticated remote bypass of access control restrictions. This issue affects all supported versions of Quarkus and other products that use the quarkus-vertx-http component for security.

This issue is assigned CVE-2023-4853 and assessed as having an Important security impact. There are mitigations available for those unable to upgrade to the fixed version.

Technical summary

Quarkus provides different methods to secure its endpoints. One of those, the HTTP security policy, can provide secured access using a path-based configuration. However, it does not correctly handle request paths containing multiple adjacent forward-slash characters when deciding if a given policy configuration must apply to the current request, causing the request to bypass the security policy entirely.

Example: 

# Policy enforcing role-based access control, named ‘role-admin’

quarkus.http.auth.permission.role-admin.paths=/service/*

Incorrectly allows access via http://<url>///service/ .

and

# Policy requiring authentication only, named ‘authenticated’

quarkus.http.auth.permission.authenticated.paths=/internal/*

Incorrectly allows access via http://<url>///internal/ .​​​​​​​

The flaw can permit information exposure and improper access to application functionality. It may also permit denial of service; yet other compromises might not be ruled out.

Mitigations

Note: All of the following proposed options that reconfigure or add classes to Quarkus projects require the affected applications to be rebuilt and redeployed. See the Load Balancer / Proxy Protection section for mitigation information that does not require changing or rebuilding the Quarkus application.

 Option 1. Apply the ‘deny’ security policy

Restrict the whole application URL space with the ‘deny’ security policy, in addition to the existing ‘authenticated’,  ‘role based access control’, or ‘permit’ policies. 

For example:

quarkus.http.auth.permission.deny.paths=/*

quarkus.http.auth.permission.deny.policy=deny

quarkus.http.auth.permission.authenticated.paths=/authenticated/*

quarkus.http.auth.permission.authenticated.policy=authenticated

quarkus.http.auth.permission.public.paths=index.html,/, /public/*

quarkus.http.auth.permission.public.policy=permit

Adding a wildcard ‘deny’ policy ensures that all requests not covered by the existing policies are blocked. If the application provides access to public resources but no ‘permit’ policy currently exists then you’ll have to introduce it, allowing access to public resources, as shown in the example above.

Note: The HTTP security policy configuration is build-time, therefore, the application has to be rebuilt and redeployed for this mitigation to take effect.

Option 2. Rerouting requests to the normalized path

Register a Vert.x route which re-routes requests to the normalized path if the current path is not normalized.

For example:

package org.acme.getting.started;

import io.vertx.ext.web.Router;

import jakarta.enterprise.event.Observes;

public class Reroute {

public void init(@Observes Router router) {

router.route().order(Integer.MIN_VALUE).handler(rc -> {

if (rc.request().path().equals(rc.normalizedPath())) {

rc.next();

} else {

rc.reroute(rc.normalizedPath());

}

});

}

}

Option 3. Register a custom HttpSecurityPolicy

Please consider using “Option 2. Rerouting requests to the normalized path” instead of this option unless you do prefer to block requests with non-normalized paths.

Register a custom policy that can block requests whose path and normalized path values differ. 

For example:

package org.acme.getting.started;

import io.quarkus.security.identity.SecurityIdentity;

import io.quarkus.vertx.http.runtime.security.HttpSecurityPolicy;

import io.smallrye.mutiny.Uni;

import io.vertx.ext.web.RoutingContext;

import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped

public class BlockingHttpSecurityPolicy implements HttpSecurityPolicy {

@Override

public Uni<CheckResult> checkPermission(RoutingContext context, Uni<SecurityIdentity> identity,

         AuthorizationRequestContext requestContext) {

     String path = context.request().path();

     String normalizedPath = context.normalizedPath();

    if (!path.equals(normalizedPath)) {

         return Uni.createFrom().item(CheckResult.DENY);

     }

    return Uni.createFrom().item(CheckResult.PERMIT);

}

}

This custom policy is registered as an ‘ApplicationScoped’ CDI bean and blocks all requests whose path and normalized path values differ. For example, if a policy secures the ‘/hello’  path, this custom policy will block requests with URLs such as ‘//hello’.

Option 4. JAX-RS: Use security annotations

If you secure JAX-RS endpoints with security policies only, then use security annotations such as ‘@Authenticated’, ‘@RolesAllowed’, and ‘@PermitAll’ to define the security policy for JAX-RS endpoints. This mitigates the flaw for JAX-RS endpoints only. Use the ‘deny’ policy or the Rerouting requests to the normalized path mitigations  to protect non-JAX-RS routes such as `’/q/openapi’, ‘/q/health’. 

Option 5. Duplicate configured paths with paths containing double forward slashes

If you decide to use the Apply the ‘deny’ security policy then it will block all requests containing two or more adjacent forward slashes with either HTTP 401 or 403 errors. Applications may want to support requests for public resources where users accidentally typed double slashes such as ‘//index.html’ in addition to ‘/index.html’. To make it work, consider duplicating the configured paths, for example:

quarkus.http.auth.permission.public.paths=/index.html,//index.html

quarkus.http.auth.permission.public.policy=permit

Additionally, if you secure JAX-RS endpoints only, which are supported by RestEasy Classic as opposed to the recommended RestEasy Reactive, duplicating all configured paths with paths containing double forward slashes will be sufficient to mitigate. Requests containing three or more adjacent paths will lead to HTTP 404 due to the specifics of the RestEasy Classic matching algorithm. This option will not work for RestEasy Reactive applications.

Option 6. Load balancer / Proxy protection

When your Quarkus application is fronted by a proxy or load balancer, you may use it to guard against the issue without having to rebuild or redeploy the Quarkus application. Consult your proxy and load balancer manual on how to make a deny list on paths that contain double slashes (//) or if it can replace any repeated forward slashes with just one slash using an expression such as '/+' -> '/'.

Technical details

The extra slashes in the request path, instead of being normalized, were evaluated as separate and expected path segments. This caused the security policy to evaluate against empty path segments, resulting in evaluation error and unexpected resolution and, ultimately, bypassing the policy altogether.

Note: The products are only vulnerable if they use or allow use of the path-based HTTP policy configuration. Products may also be affected by shipping the component in question, but may not be vulnerable and therefore are affected at a reduced impact.

Product impact

The following products ship the vulnerable classes and are affected by this flaw:

• Quarkus 2.13

• Red Hat build of Optaplanner

• Red Hat Process Automation Manager

• Red Hat Decision Manager

• Red Hat Integration Camel K

• Red Hat Integration Camel Quarkus

• Red Hat Integration Service Registry

• Red Hat Openshift Serverless

Updates for affected products

Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as erratas are available. Customers are urged to apply the available updates immediately and enable the mitigations as they feel appropriate.  

^[1] Advisory/Update link will be added once updates are live.

Diagnose

Review your security configuration, properties, and application environment files for possible usage of path-based authentication in the endpoints. If the usage of path-based authentication is found, it is advised to implement any of the mitigation methods suggested. A detection utility is not available at this time.

References

Quarkus Issue 35785 

How to use GPG to verify signed content from Product Security