Rainbows! 0.91.1 - use a less-broken parser from Unicorn

Rainbows! is an HTTP server for sleepy Rack applications. It is based
on
Unicorn, but designed to handle applications that expect long
request/response times and/or slow clients. For Rack applications not
heavily bound by slow external network dependencies, consider Unicorn
instead as it simpler and easier to debug.

Changes:

This release fixes a denial-of-service vector for deployments
exposed directly to untrusted clients.

The HTTP parser in Unicorn <= 0.97.0 would trip an assertion
(killing the associated worker process) on invalid
Content-Length headers instead of raising an exception. Since
Rainbows! and Zbatery supports multiple clients per worker
process, all clients connected to the worker process that hit
the assertion would be aborted.

Deployments behind nginx are not affected by this bug, as
nginx will reject clients that send invalid Content-Length
headers.

The status of deployments behind other HTTP-aware proxies is
unknown. Deployments behind a non-HTTP-aware proxy (or no proxy
at all) are certainly affected by this DoS.

Users are strongly encouraged to upgrade as soon as possible,
there are no other changes besides this bug fix from Rainbows!
0.91.0 nor Unicorn 0.97.0

This bug affects all previously released versions of Rainbows!
and Zbatery.

Unicorn is an HTTP server for Rack applications designed to only serve
fast clients on low-latency, high-bandwidth connections and take
advantage of features in Unix/Unix-like kernels. Slow clients should
only be served by placing a reverse proxy capable of fully buffering
both the the request and response in between Unicorn and slow clients.

Changes:

This release fixes a denial-of-service vector for derived
servers exposed directly to untrusted clients.

This bug does not affect most Unicorn deployments as Unicorn is
only supported with trusted clients (such as nginx) on a LAN.
nginx is known to reject clients that send invalid
Content-Length headers, so any deployments on a trusted LAN
and/or behind nginx are safe.

Servers affected by this bug include (but are not limited to)
Rainbows! and Zbatery. This bug does not affect Thin nor
Mongrel, as neither got the request body filtering treatment
that the Unicorn HTTP parser got in August 2009.

The bug fixed in this release could result in a
denial-of-service as it would trigger a process-wide assertion
instead of raising an exception. For servers such as
Rainbows!/Zbatery that serve multiple clients per worker
process, this could abort all clients connected to the
particular worker process that hit the assertion.

Oops, I got the subject line and version wrong :x

Zbatery is an HTTP server for Rack applications on systems that either
do not support fork(), or have no memory (nor need) to run the
master/worker model. It is based on Rainbows! (which is based on
Unicorn (which is based on Mongrel)) and inherits parts of each.
Zbatery supports your choice of all the thread/fiber/event/actor-based
concurrency models and Rack middleware that Rainbows! supports (or will
ever support) in a single process.

Changes:

This release fixes a denial-of-service vector for deployments
exposed directly to untrusted clients.

The HTTP parser in Unicorn <= 0.97.0 would trip an assertion
(killing the associated worker process) on invalid
Content-Length headers instead of raising an exception. Since
Rainbows! and Zbatery supports multiple clients per worker
process, all clients connected to the worker process that hit
the assertion would be aborted.

Deployments behind nginx are not affected by this bug, as
nginx will reject clients that send invalid Content-Length
headers.

The status of deployments behind other HTTP-aware proxies is
unknown. Deployments behind a non-HTTP-aware proxy (or no proxy
at all) are certainly affected by this DoS.

Users are strongly encouraged to upgrade as soon as possible,
there are no other changes besides this bug fix from Rainbows!
0.91.0 nor Unicorn 0.97.0

This bug affects all previously released versions of Rainbows!
and Zbatery.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs