Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Janusz Niewiadomski (funkyshisec.pl)
Date: Mon Mar 11 2002 - 15:32:37 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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
    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

    "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