CVE-2024-6875

Overview

Infinispan is an open-source in-memory data grid and distributed key/value data store. Java applications embed it as a local or clustered cache through infinispan-core, or connect to a cluster of Infinispan Server nodes through the Java Hot Rod client, infinispan-client-hotrod. Its modules are published to Maven Central under org.infinispan, and Spring Boot 2.7 manages the Infinispan 13.0 BOM.

A denial of service vulnerability (CVE-2024-6875) has been identified in the REST API of Infinispan Server, which allows authenticated attackers to exhaust the server's memory by sending repeated requests with large multipart POST bodies. The server decodes each body with a multipart decoder that it never releases, so the buffered request data accumulates until the server runs out of memory. Applications that only embed Infinispan or use the Hot Rod client do not run this REST server.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of Infinispan.

Details

Module Info

• Product: Infinispan
• Affected packages: org.infinispan:infinispan-query
• Affected versions: <14.0.31.Final, >=15.0.0.Dev01 <15.0.6.Final, =15.1.0.Dev01
• GitHub repository: https://github.com/infinispan/infinispan
• Published packages: https://central.sonatype.com/artifact/org.infinispan/infinispan-query
• Package manager: Maven
• Fixed in:
  • OSS Infinispan 14.0.31.Final, 15.0.6.Final, 15.1.0.Final
  • NES for Infinispan v13.0.24

Vulnerability Info

This Medium-severity vulnerability is found in the org.infinispan:infinispan-query package in multiple versions of Infinispan. The advisory lists that package, but the vulnerable code is in the Infinispan Server REST endpoint, which is built from the infinispan-server-rest module.

When a REST handler receives a multipart/form-data POST body, it parses the body with Netty's HttpPostMultipartRequestDecoder. The decoder keeps the request content and every decoded part (memory or disk attributes and file uploads) until destroy() is called on it. The REST server never calls destroy(), so each request leaves its decoded data behind. An authenticated client that keeps sending requests with large POST bodies makes the server accumulate this data until it fails with an out of memory error.

The advisory names the cache configuration compare API, which accepts two configurations as a multipart body. The 13.0.x REST server has no compare endpoint, but its backup restore handler, which accepts an uploaded backup archive as a multipart body, has the same flaw:

static CompletionStage<RestResponse> handleRestore(String name, RestRequest request, BackupManager backupManager,
                                                   TriFunction<String, Path, Json, CompletionStage<Void>> function) {
   ...
   boolean uploadedBackup = contentType.match(MediaType.MULTIPART_FORM_DATA);
   try {
      if (uploadedBackup) {
         FullHttpRequest nettyRequest = ((NettyRestRequest) request).getFullHttpRequest();
         DefaultHttpDataFactory factory = new DefaultHttpDataFactory(true);
         InterfaceHttpPostRequestDecoder decoder = new HttpPostMultipartRequestDecoder(factory, nettyRequest);
         DiskFileUpload backup = (DiskFileUpload) decoder.getBodyHttpData("backup");
         path = backup.getFile().toPath();

         DiskAttribute resources = (DiskAttribute) decoder.getBodyHttpData("resources");
         if (resources != null)
            resourcesJson = Json.read(resources.getString());
      }
      ...
      function.apply(name, path, resourcesJson).whenComplete((Void, t) -> {
               ...
               if (uploadedBackup) {
                  try {
                     Files.delete(path);
                  } catch (IOException e) {
                     LOG.warnf(e, "Unable to delete uploaded backup file '%s'", path);
                  }
               }
            }
      );
      return responseFuture(ACCEPTED);

The handler deletes the uploaded backup file once the restore completes, but the decoder that holds the parsed request is never destroyed, so the resources it holds are not released. Each multipart restore request therefore leaks the decoder's resources.

Mitigation

Infinispan's security policy lists only its current release lines as supported for vulnerability updates, and upstream has made no 13.0.x release since 13.0.22.Final (April 2024), so no 13.0.x release is available to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a currently supported release of Infinispan that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.