Certain malformed configuration file lines can lead to unpredictable
crashes. This bug is not exploitable by an IRC user, but has resulted
in a lot of email to the Undernet Coder Committee.
Details:
The server configuration file consists of several lines, each starting
with a single letter, followed by a colon (':'), followed by several
fields, each separated by another colon. Except for connection classes
(designated as "Y-lines"), the first three fields of all configuration
file lines are strings, represented in the C with pointers. Empty
fields are represented with NULL pointers.
Certain lines, particularly C, H, and U-lines, are searched via
particular fields. If a given field is empty, a valid configuration
entry is stored in the in-memory representation, but which contains a
NULL pointer for this field. This results in unpredictable assertion
failures during certain operations involving linking servers or
searching for U-lines. (If the assertions did not fail, string
comparisons immediately after the assertions would result in crashes.)
The next version of Undernet's ircu will contain a brand new
configuration file format. Much of the code leading to these crashes
will be rewritten, so this will not be a problem for future versions
of ircu. In the meantime, please check your server configuration. None
of the first three fields of a C, H, L, or U-line should be
empty. Examples of proper C, H, and U-lines follow. (If you are using
L-lines, please send email to [EMAIL PROTECTED] stating what you are
using them for: The Undernet Coder Committee is strongly considering
removing support for them in future versions of ircu.)
C:127.0.0.1:password:localhost.com:4400:10
H:localhost.com:*:*
U:localhost.com:org:*
Also, please be aware that ircd.conf is sensitive to whitespace.
Editing your ircd.conf on a Windows machine may result in carriage
return/newline pairs as line endings, as opposed to the UNIX standard
newline. The carriage return may be interpreted as a part of the
string and render H-lines and U-lines inoperable.
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
