Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Janusz Niewiadomski (funkyshisec.pl)
Date: Mon Mar 11 2002 - 15:32:37 CST
Name: Ecartis / Listar
Version: read the details
Vendor: The Ecartis Project. http://www.ecartis.org/
Author: Janusz Niewiadomski (funkyshisec.pl),
Wojciech Purczynski (cliphisec.pl)
Date: March 10, 2002
Multiple buffer overflow vulnerabilities as well as improper privilege
dropping in Ecartis/Listar may lead to root compromise.
Listar is a open-source software package that administers mailing lists
(similar to Majordomo and Listserv).
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
Ecartis Core Team was informed on January, 9 2002, fixed snapshot was
released next day (Ecartis 1.0.0 snapshot 20020110).
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
"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.
All current versions are affected, including latest CVS snapshot
1.0.0-20020125. Vendors were notified on Jan 13 2002 without response.
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.
Numerous exploitable vulnerabilities present in Ecartis/Listar software
may lead to local and even remote root or non-privileged user compromise.
Incorporating mailing list management functionality with mailing list
delivery agent into one single suid binary opens many security holes.
In our opinion Ecartis needs to be rewritten from scratch.
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:
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.
-- Janusz Niewiadomski iSEC Security Research http://isec.pl/