Re: Real-World Impact of Hash DoS in Lua

[Florian Weimer <fw@...>]

* Mike Pall:

> In fact, nobody should _ever_ write their own HTTP handler! This
> is absolutely not a trivial task, if you want it to be DoS-proof.

With connection keepalive, it's also imperative to get the request and
response boundaries correct, or you risk data leakage between
sessions.  This might even happen without a deliberate attack.

> Even most of the 'batteries included' HTTP handlers of other
> languages are just toys. There's only handful of web servers
> packages that have seen the necessary scrutiny and that stand a
> chance to survive an attack from a single client. But even those
> will go down from a concerted DoS attack, unless you throw tons of
> hardware at it or fight it at the network-level.

On the other hand, at one point, the request has to hit the
application code.  Then, most of the badness should have been dealt
with, but you have to cope with the remaining data.  The hash
collision issue is a bit annoying in this regard because it will go
through filters (just like the Java float parser issue).

However, there is one aspect that's conveniently ignored.  In order to
trigger collisions that really hurt, you need to send large requests
with lots of data.  Really lots of data: the proof-of-concept exploits
I've seen send 2 megabytes per request and more.  Internal memory
usage will be much higher due to per-string and per-key overhead.
Even without hash collisions, such levels of per-request memory usage
is very problematic.  Most systems have trouble recovering from memory
allocation failures, or just from swapping.  Therefore, you really
want strict limits on HTTP request size (or more generally, per-user
memory allocation), which also indirectly limits the length of hash
chains.

String interning complicates matters a bit, but it seems to me that
the Lua implementation is fairly robust if the data retained per
request is limited and the per-state heap size isn't large.