[prev in list] [next in list] [prev in thread] [next in thread] 

List:       listar-dev
Subject:    [EDev] Fwd: [funkysh@isec.pl: Ecartis/Listar multiple vulnerabilities]
From:       John Goerzen <jgoerzen () complete ! org>
Date:       2002-03-19 14:56:03
[Download RAW message or body]


Hi,

Got this message.  Please cc me on replies.  Thoughts?

Begin forwarded message:
>
> From: Janusz Niewiadomski <funkysh@isec.pl>
> To: bugtraq@securityfocus.com
> Cc: security@isec.pl
> Subject: Ecartis/Listar multiple vulnerabilities
> Date: Mon, 11 Mar 2002 00:57:33 +0100 (CET)
> Reply-To: security@isec.pl
> X-Spam-Status: No, hits=-3.0 required=5.0 
> tests=PGP_SIGNATURE,RAZOR_CHECK version=2.01
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Name:		Ecartis /  Listar
> Version:	read the details
> Vendor:		The Ecartis Project.  http://www.ecartis.org/
> Author:		Janusz Niewiadomski (funkysh@isec.pl),
>                 Wojciech Purczynski (cliph@isec.pl)
> Date:		March 10, 2002
>
>
> Issue:
> ======
>
> Multiple buffer overflow vulnerabilities as well as improper privilege
> dropping in Ecartis/Listar may lead to root compromise.
>
>
> Description:
> ============
>
> Listar is a open-source software package that administers mailing lists
> (similar to Majordomo and Listserv).
>
>
> Details:
> ========
>
> 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.
>
> 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
> 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.
>
> 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.
>
>
> Impact:
> =======
>
> 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.
>
>
> Fix:
> ====
>
> 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.
>
>
> - --
> Janusz Niewiadomski
> iSEC Security Research
> http://isec.pl/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iEYEARECAAYFAjyL8vsACgkQC+8U3Z5wpu4gEwCfYAs424U0PkfJfub5I60RPeG4
> xhUAoOxL4idOjWVA/N3+n+DgaBsG2+T2
> =JwWv
> -----END PGP SIGNATURE-----
>
>
>
>
> ----- End forwarded message -----


[prev in list] [next in list] [prev in thread] [next in thread]