RAZOR Advisory: Multiple Local Sendmail Vulnerabilities

RAZOR Advisory: Multiple Local Sendmail Vulnerabilities =======================================================  Author: Michal Zalewski  Release Date: 10/01/2001  Assigned CVE numbers: CAN-2001-0713, CAN-2001-0714, CAN-2001-0715  Topic: ------     The Sendmail mail delivery subsystem is vulnerable to multiple local    attacks that lead to information loss, information leaks and mail system    compromise.  Affected Systems: -----------------     The mail system privileges compromise affects Sendmail 8.12.0. Other    problems affect all versions up to 8.12.0.  Vulnerability 1: Mail System Compromise -- CAN-2001-0713 --------------------------------------------------------    Sendmail 8.12.0, in its default installation, is no longer using a setuid   root binary to manipulate the mail queue and submit mail. This security   enhancement is supposed to minimize the eventual impact of local Sendmail   vulnerabilities. The new Sendmail binary is setgid smmsp, where smmsp is a   special group with read-write queue access permissions.    From previous versions, Sendmail 8.12 inherits a functionality that allows   users to specify custom configuration files or configuration parameters. In   this case of processing of untrusted configurations, Sendmail was supposed   to drop all extra privileges and continue to run at user level, causing no   security risk. This mechanism worked fine in Sendmail versions prior to   8.12.0. Because of a programming error, this inherited code fails to drop   extra group privileges completely in new setgid conditions, leaving the   saved gid value untouched. By calling the setregid() function, the attacker   will be able to regain dropped privileges. Extra privileges expose a   security risk to the mail subsystem and, in specific conditions, might lead   to further privilege elevation (see discussion below).    In order to issue setregid(), the attacker has to take over control of the   program itself. A possible attack vector is to exploit configuration file   parsing code. This code is not supposed to be bullet-proof - it is intended   to parse trusted content or untrusted content, but run with no extra   privileges. We have determined that there are multiple potentially   exploitable conditions that can be triggered by custom configuration files    (-C parameter):    * Parsing one-letter macro names in rewrite rules that have the high bit set     cause a delayed crash in miscellaneous locations, e.g. the queueup()     function during sendall(). This indicates memory corruption problem:      R$-           $ó: $(dequote $1 $) < @ *LOCAL* > dequote "foo"    * The function setoption() in readcf.c file, invocation of bitnset() can     result in a memory overwrite if the following line is found in a     configuration file:        Oó some=thing      A crash occurs immediately.    * The function getmodifiers() in daemon.c, invocation of setbitn() in the     following case:         O DaemonPortOptions=Port=587, Name=MSA, M=ó    In all examples, 'ó' can be replaced with any ASCII character with the high   bit set (this causes the signed char value to be negative and the table to   be accessed outside the assigned area).    Note that our .cf parser code audit is not supposed to be complete or   accurate, and results are only provided to demonstrate the possibility of   attack. The proper solution to this problem is to fix the privilege-dropping   code.    Once the Sendmail process is controlled by the attacker, s/he can issue the   setregid() system call and gain smmsp group access level. This group is   allowed to manipulate the user-level queue (/var/spool/clientmqueue). This    allows the attacker to read and/or modify other users' mail, and to  enable   further privilege elevation due to a practice suggested by Sendmail 8.12   documentation (sendmail/SECURITY):      "In general it is necessary to clean the queue either     via a cronjob or by running a daemon, e.g.,      /PATH/TO/sendmail -L sm-msp-queue -Ac -q30m"    While Sendmail, in this particular case, is supposed to run with smmsp user   and group privileges, it fails to drop group privileges and the gid remains   set to 0. Again, the queue file processing algorithm is not bullet-proof.    This is acceptable, because ordinary users should be not able to modify   queue files. Unfortunately, due to the vulnerability described above, it   suddenly becomes a problem.    One of the potential problems in the qf parser: expired T tag in the queue   file, in conjunction with no valid Return-Path header, can cause a crash.   The failure occours when Sendmail tries to generate return envelope for   this mail and is not able to connect master SMTP daemon (which can be   DoSed or rendered unusable in other way). Because of heap corruption,   depending on run parameters and queue contents, this vulnerability can    cause a crash by following invalid pointer, freeing non-allocated memory,    etc, and, due to user-dependent queue contents, is likely to be   exploitable.    Note:   -----    We have noticed that there are other alarming symptoms related to recent   changes in Sendmail code. This condition shall not be considered a   vulnerability, but might lead to serious problems. The "harmless" practice of   giving a+x permissions to user queue (/var/spool/clientmqueue), which, at   first sight, does not cause a major security problem and might be a result   of overlooking (especially if Sendmail 8.12.x is shipped in packages),   actually allows mail system compromise. The attacker can read and/or modify    other users' mail by initiating bogus queue runs (sendmail -q -Ac -h1000 or   similar) and "taking over" the ownership of queue entries: new queue files   for existing mail that belong to other users will be owned by the attacker.   Additionally, attacker-owned queue files can be altered to cause privilege    elevation, as described above.    To prevent this condition, it should be at least documented; and at best,   Sendmail should refuse to run in an insecure environment or generate an   appropriate warning.  Vulnerability 2: Queue Manipulation and Destruction -- CAN-2001-0714 --------------------------------------------------------------------    All versions of Sendmail allow any user to process the whole mail queue,   unless this feature is administratively disabled. This feature itself is not   dangerous. Due to a programming bug, specific attacker-specified mail   delivery options will be honored. It is possible to, for example, force    Sendmail to drop queue contents by setting initial message hop count above    the limit:      sendmail -q -h1000    Specific queue entries can be targeted using parameters like -qR, -qS, etc.    This can be considered a DoS / data loss attack. Systems that do not allow    users to run the queue (RestrictQRun option) are not vulnerable to this.   RestrictQRun is not set by default.   Vulnerability 3: Debug Mode Leaks Information -- CAN-2001-0715 --------------------------------------------------------------    This is a fairly low-risk vulnerability related to user-driven queue   processing abilities. Debugging flags can be used to obtain the complete mail   system configuration, gather potentially interesting information about the   mail queue (full message path, subject, mail software, etc.) even if local    users (and the attacker) are not allowed to read the configuration or mail   queue directly. This can be achieved by issuing the following command:      sendmail -q -d0-nnnn.xxx    where nnnn and xxx specify debugging levels.    Systems that do not allow users to run the queue (RestrictQRun option)    are not vulnerable to this. RestrictQRun is not set by default.  Vendor Response and Fix Information: ------------------------------------    The vendor has been contacted, and released the following statement:    We would like to thank Michal Zalewski for bringing these problems   to our attention. We are sorry that these issues haven't been found   earlier despite extensive beta testing. In response to his advisory   we will release sendmail 8.12.1 that addresses the issues as follows:    - For operating systems where the system call setgid() does not     irrevocably give up privileges obtained via the set-group-ID binary,     three other options are available: setegid(), setregid(), and     setresgid(). Additionally sendmail checks whether the privileges     can be regained when they should have been dropped in which case     sendmail refuses to run.    - The PrivacyOptions RestrictQRun is set by default for mail submission     (submit.cf) to avoid privacy leaks or mail loss due to mailicous     local users.    - 8.12.1 prevents information leakage when sendmail has extra     privileges by disabling debugging (command line -d flag) during queue     runs and disabling ETRN when sendmail -bs is used.    - 8.12.1 limits mail submission command line flags (i.e., -G, -h,     -F, etc.) to mail submission operating modes (i.e., -bm, -bs, -bv,     etc.) when sendmail is running with extra privileges.    - Additonal test programs are distributed with sendmail that     can check whether the required functionality of system calls is     available. See test/README in 8.12.1 for further information.    - The potential memory corruption problems have been fixed.