buffer overflow in innd/art.c (possibly serious)

[Dan Riley]

innd (inn-STABLE-20030716, but it doesn't look like there are any
relevant changes in inn-STABLE-20040107) crashed repeatedly on us
today.  Examining a core file showed the stack had been smashed,
munging the value of the cp argument to ARTpost (and once that's
pointing someplace crazy innd is pretty quickly toast).  Inserting a
canary

   CHANNEL *scp = cp;

as the first auto variable, with a sprinkling of assert(scp == cp)
throughout the routine, showed the damage was in this block of code in
ARTpost (line 2187 or so):

  /* Control messages not filed in "to" get filed only in control.name
   * or control. */
  if (IsControl && Accepted && !ToGroup) {
    ControlStore = true;
    FileGlue(tmpbuff, "control", '.', ControlWord);
    if ((ngp = NGfind(tmpbuff)) == NULL)
      ngp = NGfind(ARTctl);
    ngp->PostCount = 0;
    ngptr = GroupPointers;
    *ngptr++ = ngp;
    for (isp = ngp->Sites, i = ngp->nSites; --i >= 0; isp++) {
      if (*isp >= 0) {
	sp = &Sites[*isp];
	SITEmark(sp, ngp);
      }
    }
  }

Specifically

    FileGlue(tmpbuff, "control", '.', ControlWord);

ControlWord was "alt.binaries.sounds.midi.ringtones", that's 34
characters, add on "control." is 42 characters, and tmpbuff is
char[32].  Oops.  ControlWord is snipped at SMBUF, so tmpbuff
should be sized to SMBUF + strlen("control.").

Here's the headers of the culprit (which I'm afraid we passed on
to stanford--I didn't think to poison the article until too late):

From: robot at cfl.rr.com
Control: alt.binaries.sounds.midi.ringtones
Newsgroups: alt.config
Approved: robot at cfl.rr.com
Subject: alt.binaries.sounds.midi.ringtones
Followup-To: poster
Date: Wed, 07 Jan 2004 11:17:50 -0500
Keywords: ringtone, ringtones, midi, polyphonic, ring, tone, tones, midis
Sender: robot at cfl.rr.com
Reply-To: robot at cfl.rr.com
Message-ID: <k4covvsv87a6r3n0sqp7c3s26enu34l30u at 4ax.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 25
X-Authenticated-User: $$_hxayrwju
X-Comments: This message was posted through <A href="http://www.newsfeed.com">Newsfeed.com</a>
X-Comments2: IMPORTANT: Newsfeed.com does not condone, support, nor tolerate spam or any illegal or copyrighted postings.
X-Report: Please report illegal or inappropriate use to <abuse at newsfeed.com>. Forward a copy of ALL headers INCLUDING the body. (DO NOT SEND ATTACHMENTS)
Organization: Newsfeed.com http://www.newsfeed.com 100,000+ UNCENSORED Newsgroups.
Path: newsstand.cit.cornell.edu!ngpeer.news.aol.com!feed2.newsreader.com!newsreader.com!newsfeed.media.kyoto-u.ac.jp!news-out2.spamkiller.net!news-east.newsfeeds.com!not-for-mail


It seems like this should affect a large number of systems, though the
details are going to depend on the cpu architecture.  Depending on
what cleaning is done of the headers, it could concievably make a
remote system compromise possible, not just a denial of service.

Old versions of inn are not vulnerable--newsstand.cit.cornell.edu, for
example, is immune because it's still running 2.2.2, in which the
buffer used was declared as buff[SPOOLNAMEBUFF], where SPOOLNAMEBUFF
is 512.

Probably irrelevant details: the swerver in question is
lnsnews.lns.cornell.edu, running on Tru64 4.0f.

-dan