[hunchentoot-devel] Hunchentoot effective DOS-attack

[Hans Hübner]

Hi Peter,

2009/7/6 Peter Stiernström <peter.stiernstrom at blixtvik.se>
> I had a quick peek at client-as-string and it does indeed not handle the
> sb-bsd-sockets:not-connected-error and if I put a handler-case around
> body of client-as-string returning nil when the exception appears I can
> not reproduce my problem anymore.
>
> This wouldn't provide a portable solution though :-P

This really is a bug that requires fixing in usocket.  There are
multiple issues:

- As shown in the backtrace, the problem is that the getpeername()
call fails for a socket that is not connected anymore.  SBCL does the
right thing by signalling a condition.  Other implementations (I
checked CCL) seem to behave differently, i.e. return NIL in such a
case.

- Usocket does not unify the behavior, so the implementation specific
condition percolates to the caller, Hunchentoot in this case.

- Hunchentoot is not prepared to handle conditions when creating a new
worker thread.  The call to CLIENT-AS-STRING is made when creating the
name for the handler process of a new incoming connection, and that is
done in the context of the server thread.  Therefore, the signalled
condition will stop the acceptor process.

I spent some thoughts on how a "portable solution" would look like,
but given that the Lisp implementations vary greatly in behavior,
fixing usocket would be a pretty large task that I don't have the time
to do right now.  Thus, I would propose this patch:

http://bknr.net/trac/changeset/4428?format=diff&new=4428

It handles all conditions that are signaled during worker process
creation, under the theory that we want to prevent the acceptor
process from crashing under all circumstances.  This is not a clean
solution in that it may paper over bugs, but given the limited number
of function invocations that are surrounded by a HANDLER-CASE, I'd say
that this is a proper intermediate fix.

Please give it a try and let me know if it solves the problem for you.

-Hans