HTTP endpoint and HTTP redir check are vulnerable to Brotli ("zip") bombs if Brotli support is enabled

[wandernauta]

The recently added HTTP endpoint as well as the HTTP redirection check are vulnerable to the same issue as Trifecta when it comes to accepting crafted requests and responses with a Brotli Content-Encoding, a feature that is enabled by default if simplomon is compiled on a machine that has Brotli headers present.

Again, taking an example file from here and bunzipping it, we have a small Brotli file that uncompresses to a large amount of data. When we send this file, either as part of a request to the status endpoint or as a response to a redir check, simplomon will attempt to allocate enough memory to hold the result, which exceeds the amount of available memory. The exact behavior is somewhat system-dependent, but on my machine this triggers the OOM killer, which then kills the simplomon process.

% /tmp › curl -v -H 'Content-Encoding: br' --data-binary @10GB.html.br http://127.0.0.1:8080/health
*   Trying 127.0.0.1:8080...
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> POST /health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/8.0.1
> Accept: */*
> Content-Encoding: br
> Content-Length: 27036
> Content-Type: application/x-www-form-urlencoded
> 
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

For the redir check, the following configuration allocates 10GB of memory:

httpredir{fromUrl="http://demo.52-7-242-28.nip.io", toUrl="http://example.com/"}

A possible mitigation would be the same as on the Trifecta side, that is, to disable Brotli support entirely. For simplomon, it seems unlikely that either requests or responses would benefit from compression at all.

In general, it might be sensible to document (perhaps in the README) whether it is expected that simplomon instances be available from the internet, and if not, perhaps bind to the loopback interface instead of 0.0.0.0.