net/http: invalid headers are normalized, allowing request smuggling

[FiloSottile]

net/http (through net/textproto) used to accept and normalize invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a Go server is used behind a reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or request smuggling, the latter if requests from separate clients are multiplexed onto the same connection by the proxy. Such invalid headers are now rejected by Go servers, and passed without normalization to Go client applications.

This issue is CVE-2019-16276 and is fixed in Go 1.13.1 and Go 1.12.10.

[FiloSottile]

@gopherbot Please open backport issues for this. This was a security problem.

[gopherbot]

Backport issue(s) opened: #34541 (for 1.12), #34542 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[thaJeztah]

Looks like this fix is not in master, only in the release branches, correct?

[FiloSottile]

Looks like this fix is not in master, only in the release branches, correct?

At the moment, correct. I will land it in master today.

[gopherbot]

Change https://golang.org/cl/197503 mentions this issue: net/textproto: don't normalize headers with spaces before the colon

[thaJeztah]

👍 I just noticed it, looking for the commit it was cherry-picked/backported from (which was missing)

[thausler786]

Thanks for remediating this vulnerability so fast! We've got a couple of questions, mostly bookkeeping:

1. When do you plan to publish the details of this vulnerability in MITRE?
2. Do you have a CVSS score for this vulnerability?

[FiloSottile]

Just notified MITRE of the publication. We never assign the CVSS on our side.

[sporkmonger]

One thing that's potentially worth noting, even after the fix, it's still difficult for handler code to identify the characteristics of a desync payload. There's enough information to reliably identify it's happening inside the textproto package, but not when you've got a *http.Request. This makes it challenging to write detection logic for this type of attack in Go without duplicating a substantial portion of Go's HTTP stack or using lower-level functions that complicate the use of middleware, etc. If you were trying to write, e.g. a web application firewall in Go, visibility on malicious traffic is pretty useful.