[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. :)
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)
-----BEGIN PGP SIGNED MESSAGE-----
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----
ircd-ratbox mailing list
ircd-ratbox at lists.ratbox.org
More information about the ircd-ratbox