[ircd-ratbox] ircd-ratbox denial of service advisory

Paul-Andrew Joseph Miseiko esoteric at teardrop.ca
Thu Jun 17 21:38:18 EDT 2004

This has to be one of the most amusing exploits I have ever read about. :)

-----Original Message-----
From: ircd-ratbox-bounces at lists.ratbox.org
[mailto:ircd-ratbox-bounces at lists.ratbox.org] On Behalf Of Aaron Sethman
Sent: June 17, 2004 4:25 PM
To: ircd-ratbox at lists.ratbox.org
Subject: [ircd-ratbox] ircd-ratbox denial of service advisory

The original text of the message below can be found at

The bug mentioned in the advisory below has been fixed in 
ircd-ratbox-1.5-2 and all users are highly encouraged to upgrade to this 
version.  For those of you following the development of 2.0, the bug 
has been fixed in the CVS tree and will be in the upcoming 2.0-rc7.

Thanks to einride for finding this issue and a concise report(and patch)



Hash: SHA1

Name     : ircd-hybrid-7/ircd-ratbox remote DoS
Date     : June 14th 2004
Author   : Erik Sperling Johansen <einride at einride.org>
Severity : Medium - High

This has been tested on most the ircd versions currently used on EFNet.
Other ircds may be affected.

   ircd-hybrid 7.0 stable, later versions not tested
   ircd-ratbox 1.4-2, 1.5-1, 2.*, most likely all versions
Not Affected:
   ircd-hybrid 6 - current version
   csircd - current version

Due to faulty logic in the socket dequeuing mechanism used in hybrid 7 
and the derivated ircd-ratbox, it is possible to severely lag an irc 
server using a low-bandwidth DoS attack.

Client connections to the ircd are subject to a burstable rate limit, 
specified as messages per second, and implemented as a simple token 
bucket. This rate limit will cause a client to exit with an "Excess 
Flood" error if data is sent to fast. This rate limit is not used for 
connected servers, and more important; neither for connections that 
are not yet registered as a client or a server.

Processing of received data is a 2-stage operation. First, data is 
read off ready sockets, split into lines and queued up in a "linebuf" 
linked list with buffers allocated from a blockheap. Each line will 
cause a 537-byte block of data to be allocated.

Then, these lines are processed by parse_client_queued. If the sender 
is a server, there's no ratelimit, fine. If the sender is a client, 
there's a ratelimit leading to a closed connection if it's exceeded, 
works like a charm. If the sender is "Unknown", there's a fixed 
ratelimit of MAX_FLOOD (default 5) lines per main loop iteration. This
ratelimit does not cause the connection to be closed if it is exceeded,
processing is simply postponed until next main loop iteration.

So, if you haven't registered, you're not subject to rate limits. Each
line you send causes a 537 byte buffer to be allocated. Your lines are
dequeued slowly. Starts to look like a possible memory exhaustion? Now,
add to this that " \n" is considered a queueable line. Yep, 2 bytes 
sent cause a 537 byte heap block to be queued and way too slowly



This little app can make any of the vulnerable ircds severly lagged and
often totally unresponsive, with usage of no more than 100-150K/sec 
bandwidth. The effects stay behind several minutes after the flooding 
connections have been terminated. No warnings are given with the 
default log levels of the affected ircds.

- - Upgrade to hybrid-6 or csircd
- - Patch hybrid-7 with http://www.einride.org/adv/hyb7-adv-fix.diff
- - Patch ratbox 1.4/1.5 with http://www.einride.org/adv/ratbox-adv-fix.diff

Erik S. Johansen <einride at einride.org>

einride at EFNet - co-admin irc.banetele.no
Version: GnuPG v1.2.2 (GNU/Linux)

ircd-ratbox mailing list
ircd-ratbox at lists.ratbox.org

More information about the ircd-ratbox mailing list