SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (E-mail Server)  >   Sendmail Vendors:   Sendmail Consortium
Sendmail Security Holes Let Local Users Obtain Elevated Privileges on the System, Access the E-mail Queue, and Cause Information Loss
SecurityTracker Alert ID:  1002474
SecurityTracker URL:  http://securitytracker.com/id/1002474
CVE Reference:   CVE-2001-0713, CVE-2001-0714, CVE-2001-0715   (Links to External Site)
Updated:  Dec 1 2003
Original Entry Date:  Oct 2 2001
Impact:   Denial of service via local system, Disclosure of system information, Disclosure of user information, Modification of user information
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): 8.12.0 and prior
Description:   BindView's RAZOR security team warned of multiple vulnerabilities in Sendmail. The security holes allow a local user to obtain elevated privileges on the system.

Several vulnerabilities were reported:

1) It is reported that a programming error in version 8.12.0 caused Sendmail to fail to drop extra privileges and run at the user level when processing untrusted, user-supplied configurations. The software reportedly retains the saved group id (gid) of 'smmsp'. A local user can call the setregid() function to regain these 'dropped' privileges. To do this, the local user must take control of Sendmail. RAZOR reports tht that can be done by exploiting various aspects of the configuration file parsing code, as described in the Source Message.

Once the local user has gained control of the Sendmail process, the local user can issue the setregid() system call and gain smmsp group access permissions. With these group privileges, the local user can access and modify the user-level queue (/var/spool/clientmqueue), reading or modifying the mail of other users. It may also be possible to obtain elevated privileges (root level group id of "0") via methods vaguely described in the Source Message.

2) It is reported that a programming bug in Sendmail allows a local user to specify mail delivery options that will be inadvertently processed by Sendmail. For example, the local user can force Sendmail to drop queue contents by setting initial message hop count above the limit with the following command:

sendmail -q -h1000

Specific queue entries can apparently be targeted using parameters such as -qR and -qS. This can lead to data loss.

Sendmail systems that do not permit users to run the queue (RestrictQRun option) are not affected by this vulnerability.

3) Information may reportedly be leaked in debug mode. A local user can use debugging flags to obtain the complete mail system configuration and gather potentially sensitive information about the mail queue (e.g., full message path, subject, mail software), such as with the following command:

sendmail -q -d0-nnnn.xxx

where nnnn and xxx specify debugging levels.

It is reported that Sendmail systems that do not allow users to run the queue (RestrictQRun option) are not affected by this vulnerability.

Impact:   A local user could gain elevated privileges ('smmsp' group privileges) and access the client mail queue. A local user can cause Sendmail to drop queue contents. A local user can also gain information about the sendmail configuration.
Solution:   The vendor has released a fix (8.12.1), available from the Vendor URL. The vendor has also released the following information regarding the fix:

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.

Vendor URL:  www.sendmail.org/ (Links to External Site)
Cause:   State error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Caldera Issues Fix for OpenLinux) Sendmail Security Holes Let Local Users Obtain Elevated Privileges on the System, Access the E-mail Queue, and Cause Information Loss
The vendor has described how to fix the problem for sendmail on Caldera OpenLinux.
(Caldera Issues Fix for OpenServer) Sendmail Security Holes Let Local Users Obtain Elevated Privileges on the System, Access the E-mail Queue, and Cause Information Loss
The vendor has released a fix for OpenServer.
(Red Hat Issues Fix) Sendmail Security Holes Let Local Users Obtain Elevated Privileges on the System, Access the E-mail Queue, and Cause Information Loss
The vendor has released a fix.
(SGI Describes Workaround) Re: Sendmail Security Holes Let Local Users Obtain Elevated Privileges on the System, Access the E-mail Queue, and Cause Information Loss
SGI has described a temporary workaround.



 Source Message Contents

Subject:  RAZOR advisory: multiple Sendmail vulnerabilities



RAZOR Advisory: Multiple Local Sendmail Vulnerabilities
=======================================================

Author: Michal Zalewski <lcamtuf@razor.bindview.com>
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:


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


    A crash occurs immediately.

  * The function getmodifiers() in daemon.c, invocation of setbitn() in the
    following case:
 

  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.

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC