[UNIX] Ecartis / Listar multiple vulnerabilities
From: support@securiteam.comDate: 03/15/02
- Previous message: support@securiteam.com: "[UNIX] GNU fileutils Recursive Directory Removal Race Condition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Fri, 15 Mar 2002 12:25:59 +0100 (CET)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
Ecartis / Listar multiple vulnerabilities
------------------------------------------------------------------------
SUMMARY
<http://www.ecartis.org/> Listar is an open-source software package that
administers mailing lists (similar to Majordomo and Listserv).
Multiple buffer overflow vulnerabilities as well as improper privilege
dropping in Ecartis / Listar may lead to root compromise.
DETAILS
Remotely exploitable buffer overflow in address_match()
All versions of Listar and versions prior 1.0.0 snapshot 20020125 of
Ecartis, contain a 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, a
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 it has not been published at this
time.
The Ecartis Core Team was informed on January, 9 2002, fixed snapshot was
released the next day (Ecartis 1.0.0 snapshot 20020110).
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 the above UID/GID initialization the UID is still equal to root and
no UIDs are not changed at all (at least on Linux, implementation of
setuid/setgid varies on other systems).
Working privileges are dropped correctly 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 unprivileged 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 safest 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, no response has been
received.
Multiple local vulnerabilities
Ecartis / Listar contains many local buffer overflows and other security
holes. Most of these are very easily exploitable.
Impact:
Numerous exploitable vulnerabilities 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.
Fix:
Only the first issue has been fixed in the latest snapshot of Ecartis
development version. The Exartis development team has released a statement
and fix information on the listar-announce mailing list:
<http://marc.10east.com/?l=listar-announce&m=101452659032650&w=2>
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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:funkysh@isec.pl> Janusz
Niewiadomski, <mailto:cliph@isec.pl> Wojciech Purczynski from
<http://isec.pl/> iSEC Security Research.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[UNIX] GNU fileutils Recursive Directory Removal Race Condition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
