Denial of Service using invalid Content-Length header

Hello,

during a pentest we oberved an interesting behaviour of some web
servers: When we send a POST-request to the web server using some
value in the Content-Length header >0 (say, n), but the length of the
content of the request is less than this value (e.g. n-k), then the
server waits for the remaining (k) bytes.

Because TCP is a very simple protocol, it is possible to send a
POST-request without maintaining a client state. Therefore, a client
can send a large number of requests in a very short time; the server
creates a connection for every request until there are no more
resources available. The number of simultanious "connections" depends
on the implementation, but it is limited, which is the point. An
attacker may continously try to send POST-requests to the server,
which result in a denial of service of the web server, as long as the
attacker process runs. This is some kind of HTTP-specific SYN-flood.

This kind of vulnerability exists in nearly every network protocol,
that dooes not stream; it works as follows:
attacker: "I have <n> byte for you"
server: "Okay, I'm listening..."
attacker: <sending <n-k> bytes>
server: <waiting for <k> bytes> until the connection times out

As attachment you receive a proof of concept exploit.

A possible mitigation would be to require SSL or TLS, as this forces
the attacker to maintain a state, so that the attacker needs as much
resources as the attacked server.

Another (not very mighty) mitigation could be to provide an
intermediate layer between TCP and HTTP to handle meta information.
Only after receiving the full content, the immediate layer would
forward the content to the HTTP layer. The immediate layer could use
the round trip time to calculate a timeout that is as short as
possible...

One could also restrict the number of TCP-Segments (and IP-packets)
per POST-requests.

Restricting the number of parallel connections per IP address does not
work, as many clients use proxy servers.

I have no idea how to really prevent this kind of attack, maybe
someone in this mailing-list knows how...

Regards, Jan