[9448] in bugtraq
Re: NOBO denial of service
daemon@ATHENA.MIT.EDU (Flavio Veloso)
Tue Feb 9 18:34:23 1999
Date: Tue, 9 Feb 1999 16:59:44 -0200
Reply-To: Flavio Veloso <flaviovs@CENTROIN.COM.BR>
From: Flavio Veloso <flaviovs@CENTROIN.COM.BR>
X-To: "Andrew J. Gavin" <gavina@RIVER.IT.GVSU.EDU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.HPP.3.95.990204165100.7936B-100000@river.it.gvsu.edu>
On Thu, 4 Feb 1999, Andrew J. Gavin wrote:
> As reported by i-kran@USA.NET approximately a week ago, nobo (a back
> orifice scanning detector) has a buffer overflow problem that will crash
> the program remotely. Sending a UDP packet (larger than 1024 bytes) will
> give the error:
>
> A network error has ocurred: Message too long (10040-92)
>
> Sending 15 of these packets (the minimum required) will crash nobo (stack
> fault in kernel32.dll), with NOTHING recorded to the log file or to the
> screen.
(...)
Although this doesn't look like a buffer overflow (it is not a buffer
overflow in NOBO code), it's really a DoS. NOBO uses "async select" to
know when data is waiting to be read in its socket. For those people
which doesn't know how this feature work, Windows send an ordinary
window message to NOBO whenever its socket has data to be read.
The problem seems to be that NOBO isn't dealing with the packet fast
enough and, as messages are being delivered (directly to the message
proc instead of being posted to the message queue), Windows can't keep
up with its call stack and segfault.
Anyway, a new version of NOBO (1.3) was released to handle this issue,
the fact it wasn't logging the IP address of big packets received,
plus flood detection along with other features. NOBO can be retrieved
from its site at http://web.cip.com.br/nobo/.
--
Flavio
