[IRCServices Coding] Notice regarding v5.0.12 (fwd)

[Elijah]

I think it's forgivable just this once :P

-----Original Message-----
From: ircservices-coding-bounces at ircservices.za.net
[mailto:ircservices-coding-bounces at ircservices.za.net] On Behalf Of Andrew
Church
Sent: Thursday, February 27, 2003 5:37 AM
To: ircservices-coding at ircservices.za.net
Subject: [IRCServices Coding] Notice regarding v5.0.12 (fwd)


     I broke my own rules by posting detailed technical info to the
general-use list.  Oops.  Anyway, if you missed it there, here's the post:

     I should have mentioned it explicitly in the release notes, but one of
the fixes in version 5.0.12 is a workaround for a bug, possibly a security
hole, which can crash Services, and anyone using version 5.0.0 through 11
should upgrade to 5.0.12 immediately.  (4.5 and earlier versions may be
affected as well, though I have not heard any reports of 4.5.x crashing due
to this particular problem.)

     The reason I say "possibly" a security hole is because the direct cause
of the crash is a case which should not be able to occur in the first place,
which probably means I screwed up somewhere and haven't found it yet, and in
any case means that I can't say for certain whether the bug is limited to
crashing Services or can be abused in other ways.

     For the curious, it seems to be possible to get a nickname's language,
NickGroupInfo.language, set to 12 (which is the value of NUM_LANGS, the
constant defining the number of languages Services supports, though I don't
know whether this is related to the problem); since this value is used to
index an array of size NUM_LANGS (12), it should never be outside the range
0 through NUM_LANGS-1 (11), and when the 12 is used to index the language
text array, Services tries to read through a NULL pointer and crashes. There
was supposed to be a check on the language value at database load time, to
make certain that both the value is in range and that the language selected
is actually available, but this check was only being applied to the language
value in the version 4.5 compatibility data, and not to the value stored in
the 5.0-specific data area.  This oversight was corrected in version 5.0.12,
and the language value is now properly checked on database load; invalid
values will be set to LANG_DEFAULT (-1), which means "use the value of
DEF_LANGUAGE in defs.h".

     If anyone can pinpoint how NickGroupInfo.language can get set out of
range, you'll have my gratitude.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/
------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://www.ircservices.za.net/mailman/listinfo/ircservices-coding