[hunchentoot-devel] Hunchentoot effective DOS-attack
Hans Hübner
hans.huebner at gmail.com
Mon Jul 6 11:22:40 UTC 2009
Peter,
try this:
http://bknr.net/trac/changeset/4434?format=diff&new=4434
-Hans
On Mon, Jul 6, 2009 at 13:21, Peter
Stiernström<peter.stiernstrom at blixtvik.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Hans,
>
> Hans Hübner wrote:
>> Peter, as I cannot reproduce the problem myself, can you please post a
>> stack backtrace? Thanks!
>
> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
> BREAK was entered because of *BREAK-ON-SIGNALS* (now rebound to NIL).
> [Condition of type SIMPLE-CONDITION]
>
> Restarts:
> 0: [CONTINUE] Return from BREAK.
> 1: [REASSIGN] Return from BREAK and assign a new value to
> *BREAK-ON-SIGNALS*.
> 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Hunchentoot
> listener (*:8000)" RUNNING {C42AAE9}>)
>
> Backtrace:
> 0: (BREAK "~A~%BREAK was entered because of *BREAK-ON-SIGNALS* ~\n
> (now rebound to NIL)." #<UNBOUND-VARIABLE *ACCEPTOR*
> {AD37FC1}>)
> 1: (SIGNAL #<UNBOUND-VARIABLE *ACCEPTOR* {AD37FC1}>)[:EXTERNAL]
> 2: (ERROR UNBOUND-VARIABLE)[:EXTERNAL]
> 3: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))
> 4: (SB-KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER #<unavailable argument>
> #.(SB-SYS:INT-SAP #XB5DFFEF0) #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP
> #XB5DFFBDC :TYPE (* (STRUCT SB-VM::OS-CONTEXT-T-STRUCT))> (14))[:EX..
> 5: (SB-KERNEL:INTERNAL-ERROR #.(SB-SYS:INT-SAP #XB5DFFBDC)
> #<unavailable argument>)
> 6: ("foreign function: #x806480C")
> 7: ("foreign function: #x8052BCC")
> 8: ("foreign function: #x8056BD3")
> 9: (HUNCHENTOOT:LOG-MESSAGE :ERROR "Error while creating worker thread
> for new incoming connection: ~A")[:EXTERNAL]
> 10: ((SB-PCL::FAST-METHOD HUNCHENTOOT:HANDLE-INCOMING-CONNECTION
> (HUNCHENTOOT:ONE-THREAD-PER-CONNECTION-TASKMASTER T)) ..)
> 11: ((SB-PCL::FAST-METHOD HUNCHENTOOT:ACCEPT-CONNECTIONS
> (HUNCHENTOOT:ACCEPTOR)) #<unavailable argument> #<unavailable argument>
> #<HUNCHENTOOT:ACCEPTOR (host *, port 8000)>)
> 12: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
> 13: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477))
> 14: (SB-THREAD::CALL-WITH-MUTEX ..)
> 15: ((LAMBDA ()))
> 16: ("foreign function: #x806480C")
> 17: ("foreign function: #x8052C21")
> 18: ("foreign function: #x805BD9D")
> 19: ("foreign function: #xB7FB84C0")
>
> I found that not attempting to log a message solved this remaining problem.
>
> Thank you very much for your help!
>
> /Peter
>
>>
>> 2009/7/6 Peter Stiernström <peter.stiernstrom at blixtvik.se>:
>> Hans,
>>
>> I should have realised I was editing the lispworks implementation myself
>> had I only had a cup of coffee this morning :-P
>>
>> Now when I tried your patch out I still get hangups but this is another
>> kind of hangup:
>>
>> debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "Hunchentoot
>> listener (*:8000)" RUNNING {AD467D1}>:
>> The variable HUNCHENTOOT:*ACCEPTOR* is unbound.
>>
>> I am trying this out with the hunchentoot default page by the way.
>>
>> /Peter
>>
>> Hans Hübner wrote:
>>>>> 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:
>>>>> 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
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>>> _______________________________________________
>>>>> tbnl-devel site list
>>>>> tbnl-devel at common-lisp.net
>>>>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>>
>
>> _______________________________________________
>> 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
>
> iEYEARECAAYFAkpR3kcACgkQ0brSZD05ZzDxywCdFzn0tdVZb35stsaCZL4uPSw5
> N5wAn1FC1VTcJyNV+c+bzIpLFfTAyMfW
> =k68p
> -----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