Re: innd 2.2.2 remote buffer overflow

[rra () STANFORD EDU (Russ Allbery)]

Are you aware that there are addresses for reporting bugs in INN?  Did you
even investigate reporting this to them first?  My turnaround on patching
security bugs is pretty fast, and then you could have included a patch in
your message.

Very poor form.

Michal Zalewski <lcamtuf () TPI PL> writes:

> Newest innd 2.2.2, probably the most popular usenet news server (as well
> as previous versions) contain remotely exploitable, trivial on-stack
> buffer overflow in control articles handler.

> Offending piece of code (in innd/art.c, function ARTcancelverify):

>     if (!EQ(local, p)) {
>         files = NULL;
>         (void)sprintf(buff, "\"%.50s\" wants to cancel %s by \"%.50s\"",
>                       p, MessageID, local);
>         ARTlog(Data, ART_REJECT, buff);
>     }

> Where buff (local stack buffer) is SMBUF bytes long (it means, 256
> bytes), but MessageID can be up to 1000 almost bytes long. This code is
> reached when cancel request is sent to special newsgroup (called
> 'control'), and cancel request contains valid Message-ID, but
> From/Sender fields are different in cancel request and in original
> posting.

Note that this code is only ever executed if the option "verifycancels" is
enabled in inn.conf.  This is *not* the default, and has been recommended
against for some time now since it really doesn't do any real good.

Obvious fix:

--- inn/innd/art.c      2000/06/05 22:39:52     1.142
+++ inn/innd/art.c      2000/06/06 19:31:56     1.143
@@ -1042,7 +1042,7 @@
     HeaderCleanFrom(p);
     if (!EQ(q, p)) {
         token = NULL;
-       (void)sprintf(buff, "\"%.50s\" wants to cancel %s by \"%.50s\"",
+       (void)sprintf(buff, "\"%.50s\" wants to cancel %.70s by \"%.50s\"",
                       p, MessageID, q);
         ARTlog(Data, ART_REJECT, buff);
     }

I'm committing this to the repository now, and it should show up in STABLE
snapshots tomorrow.  Those folks who want to run with verifycancels turned
on should get the latest STABLE snapshot from /isc/inn/snapshots on
ftp.isc.org sometime after 4am PDT the next morning.  We were planning on
getting a 2.2.3 bug fix release out shortly; I'll accelerate that.

Workaround in the meantime is to turn off verifycancels in inn.conf, which
I recommend anyway as it doesn't serve any actual purpose any more.  This
whole block of code will likely be removed for INN 2.4.

Note that due to the syntax checking INN performs on message IDs, this
will be mildly difficult to exploit, although it's probably at least
theoretically possible.

--
Russ Allbery (rra () stanford edu)             <http://www.eyrie.org/~eagle/>