net/http: GET request hangs if "Content-Length" reqest-header field ist set (possible DoS vulnerability)

[je4]

What version of Go are you using (go version)?

PS C:\WINDOWS\System32> go version
go version go1.12.7 windows/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

PS C:\WINDOWS\System32> go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\juergen.enge\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\daten\go
set GOPROXY=
set GORACE=
set GOROOT=c:\go
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\JUERGE~1.ENG\AppData\Local\Temp\go-build111174446=/tmp/go-build -gno-record-gcc-switches

What did you do?

sending a GET request to the native go http server with "Content-length" request parameter

package main

import (
	"log"
	"net/http"
)

func main() {
	server := &http.Server{Addr: "localhost:80"}

	log.Fatal(server.ListenAndServe())

}

What did you expect to see?

immediate response with error code 404 page not found (<2ms)

What did you see instead?

request hangs for very long time (>1min, client kills connection).

Initial debugging

it seems, that the function call w.finishRequest() in func (c *conn) serve(ctx context.Context) from server.go does not return. There is a problem in flushing the write buffer...

[av86743]

If you are sending non-zero Content-Length and not providing data of that length, what else would you expect?

[je4]

since a request body does not make any sense in most cases for a GET request, the idle-timeout for waiting for the body data could be automatically decreased.
with the actual status, i feel, that most golang webservers could have a problem with long running requests if there are many of them...
if you are using a handler which does not read the request body, the handler is finished while the system is waiting for the request body...

[FiloSottile]

For this to be a security issue, it should bypass the server timeouts, as otherwise there are a number of ways to get the server to wait until the timeout.

Could you provide the code or command you are using to generate the request?

[je4]

i have used the "Advanced REST Client" (https://install.advancedrestclient.com/install)
the content-length variable remained while switching from POST to GET

[je4]

Further investigation shows, that an nginx server which serves static files seems to ignore this field. nginx with php-fpm activated folder shows the same behaviour...

• https://www.google.com/ (Error 400 (Bad Request)!!1)
• https://www.spiegel.de (server timeout: ~5sec, then displays normal page)
• https://www.cnn.com (client timeout)
• https://www.ibm.com (seems to ignore field)
• https://www.microsoft.com (seems to ignore field)
• https://www.facebook.com (client timeout)
• https://www.twitter.com (Error 400 Bad Request)

[lucasmoten]

From this..

if you are using a handler which does not read the request body, the handler is finished while the system is waiting for the request body

I believe appropriate course of action is to have all handlers read the request body to the end, and make use of ReadTimeout and ReadHeaderTimeout on Server.

[je4]

I believe appropriate course of action is to have all handlers read the request body to the end, and make use of ReadTimeout and ReadHeaderTimeout on Server.

I am not sure about the definition of "end". If there's a content length given and the data is needed the end correlates with the data length.
Timeout is a very good thing. But for handlers which do not use any request body data I like the "Error 400 Bad Request" solution because no client has any reason to send this data.
This could be done for the handlers shipped with go.

[odeke-em]

@je4 thank you for this report! So we've been thinking about this for a while as per #13722 /cc @bradfitz and in 2016 @bradfitz added a great suggestion to perhaps make an opt-in knob #13722 (comment) to accept GET bodies.

My data point to accept bodies with GETs is that in the wild and even widely encouraged is Elastic search which permits GET with bodies e.g. https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-body.html.

Your reference in #33269 (comment) doesn't necessarily apply as apples-to-apples because most of those are consumer sites whereas Go creates web servers so the business logic is what you are comparing yet this is a general purpose web server.

[odeke-em]

I'd say let's close this issue and move the discussion and advocacy to issue #13722, please let me know what you think @je4.