[hunchentoot-devel] Hunchentoot effective DOS-attack

Hans Hübner hans.huebner at gmail.com
Mon Jul 6 09:15:04 UTC 2009


Peter,

sorry, I am not able to reproduce the problem myself, so I made the
patch blindly and made a mistake, working on the Lispworks code rather
than the portable code that affects you.  Please look at the first
hunk of this diff:

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

and let me know if that does it for you.

Sorry,
Hans

On Mon, Jul 6, 2009 at 11:09, Peter
Stiernström<peter.stiernstrom at blixtvik.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Hans,
>
> Hans Hübner wrote:
>> 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.
>
> I tried your suggested patch but I can't seem to be able to get it to
> catch the exception for me. Were you able to duplicate the error
> yourself to verify that the suggested patch does indeed work? Since I am
> using the 1.0.0 hunchentoot release I couldn't just apply your patch but
> added the handler-case by hand and thus ended up with this in
> taskmaster.lisp:
>
> (defmethod handle-incoming-connection ((taskmaster
> one-thread-per-connection-taskmaster) handle)
>  (incf *worker-counter*)
>  ;; check if we need to perform a global GC
>  (when (and *cleanup-interval*
>             (zerop (mod *worker-counter* *cleanup-interval*)))
>    (when *cleanup-function*
>      (funcall *cleanup-function*)))
>  (handler-case
>      (mp:process-run-function (format nil "Hunchentoot worker \(client:
> ~{~A:~A~})"
>                                       (multiple-value-list
>                                        (get-peer-address-and-port handle)))
>                               nil #'process-connection
>                               (taskmaster-acceptor taskmaster) handle)
>    (error (cond)
>      (log-message *lisp-errors-log-level*
>                   "Error while creating worker thread for new incoming
> connection: ~A" cond))))
>
> /Peter
>
>
>>
>> -Hans
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
> - --
> Med vänlig hälsning,
>
> Peter Stiernström
> 0708-810932
> Blixtvik AB
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkpRv0QACgkQ0brSZD05ZzDvgQCcDecaau+Hq35HtXoZkrg0EwRz
> cLAAnR6IgD6sE5PxkD6bs1Jf6wj0b+N7
> =eUDk
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>




More information about the Tbnl-devel mailing list