Starlet before 0.33 for Perl has request-handling flaws
A large Content-Length can kill a worker, and chunked bodies from 0.20 can exhaust CPU.
HTTP response desync in Starlet before 0.33
Starlet before 0.33 does not pass the request method to its response writer, so bodies (or a chunked terminator) are sent on HEAD, 204, and 304 responses. On persistent or pipelined HTTP/1.1 connections—which stay open even when keep-alive is off—a client or shared proxy can treat those extra bytes as the next response and desynchronize clients. Anyone who can send HEAD or pipelined requests to a Starlet server can trigger it.
What to do: Upgrade Starlet to 0.33.
| Product | Affected | Fixed in |
|---|---|---|
| Starlet | before 0.33 | 0.33 |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Starlet versions before 0.33 for Perl send a body in responses to HEAD requests, corrupting the next response on a persistent or pipelined connection. The request method is not passed to the response writer, so whatever body the application returns for a HEAD request is sent. With Plack::Middleware::Head the body is empty, but an HTTP/1.1 response without a Content-Length header still gets the chunked encoding terminator. Responses with status 204 or 304 are also sent with their body. Pipelined GET and HEAD requests keep the connection open even when keep-alive is disabled, which is the default. A client or proxy reading the connection takes the extra bytes as the start of the next response, which may desynchronize a proxy that shares the connection across clients.
A large Content-Length can kill a worker, and chunked bodies from 0.20 can exhaust CPU.
Today 1.4K readers · 2.5K views · 1.9K reads · all time 160K views