Vulnerability GHSA-5vcm-3xc3-w7x3

High Risk

4 years ago

Response Splitting from unsanitized headers

0.15.0 and 0.15.1 and 0.15.2 and 0.15.3 and 0.15.4 and 0.15.5 and 0.15.6 and 0.15.7 and 0.15.8 and 0.15.9 and 0.15.10 and 0.15.11 and 0.15.12 and 0.15.13 and 0.15.14 and 0.15.15 and 0.15.16 and 0.16.0 and 0.16.1 and 0.16.2 and 0.16.3 and 0.16.4 and 0.16.5 and 0.16.6 and 0.19.0

Summary

Response Splitting from unsanitized headers

Details

Impact

http4s is vulnerable to response-splitting or request-splitting attacks when untrusted user input is used to create any of the following fields:

Header names (Header.nameå
Header values (Header.value)
Status reason phrases (Status.reason)
URI paths (Uri.Path)
URI authority registered names (URI.RegName) (through 0.21)

The following backends render invalid carriage return, newline, or null characters in an unsafe fashion.

	blaze-server	ember-server	blaze-client	ember-client	jetty-client
header names	⚠	⚠	⚠	⚠	⚠
header values	⚠	⚠	⚠	⚠
status reasons	⚠	⚠
URI paths			⚠	⚠
URI regnames			⚠ < 0.22	⚠ < 0.22

For example, given the following service:

import cats.effect._
import org.http4s._
import org.http4s.dsl.io._
import org.http4s.server.blaze.BlazeServerBuilder
import scala.concurrent.ExecutionContext.global

object ResponseSplit extends IOApp {
  override def run(args: List[String]): IO[ExitCode] =
    BlazeServerBuilder[IO](global)
      .bindHttp(8080)
      .withHttpApp(httpApp)
      .resource
      .use(_ => IO.never)

  val httpApp: HttpApp[IO] =
    HttpApp[IO] { req =>
      req.params.get("author") match {
        case Some(author) =>
          Ok("The real content")
            .map(_.putHeaders(Header("Set-Cookie", s"author=${author}")))
        case None =>
          BadRequest("No author parameter")
      }
    }
}

A clean author parameter returns a clean response:

curl -i 'http://localhost:8080/?author=Ross'

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=Ross
Date: Mon, 20 Sep 2021 04:12:10 GMT
Content-Length: 16

The real content

A malicious author parameter allows a user-agent to hijack the response from our server and return different content:

curl -i 'http://localhost:8080/?author=hax0r%0d%0aContent-Length:+13%0d%0a%0aI+hacked+you'

HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Set-Cookie: author=hax0r
Content-Length: 13

I hacked you

Patches

Versions 0.21.29, 0.22.5, 0.23.4, and 1.0.0-M27 perform the following:

If a status reasoon phrase is invalid, it is dropped. Rendering is optional per spec.
If a header name is invalid in a request or response, the header is dropped. There is no way to generically sanitize a header without potentially shadowing a correct one.
If a header value is invalid in a request or response, it is sanitized by replacing null (\u0000), carriage return (\r), and newline (\n) with space ( ) characters per spec.
If a URI path or registered name is invalid in a request line, the client raises an IllegalArgumentException.
If a URI registered name is invalid in a host header, the client raises an IllegalArgumentException.

Workarounds

http4s services and client applications should sanitize any user input in the aforementioned fields before returning a request or response to the backend. The carriage return, newline, and null characters are the most threatening.

Not all backends were affected: jetty-server, tomcat-server, armeria, and netty on the server; async-http-client, okhttp-client, armeria, and netty as clients.