[UNIX] Multiple Local Sendmail Vulnerabilities

From: support@securiteam.com
Date: 10/03/01 

From: support@securiteam.com
To: list@securiteam.com
Subject: [UNIX] Multiple Local Sendmail Vulnerabilities
Message-Id: <20011003211433.7EA2E138C2@mail.der-keiler.de>
Date: Wed,  3 Oct 2001 23:14:33 +0200 (CEST)

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

  Multiple Local Sendmail Vulnerabilities
------------------------------------------------------------------------

SUMMARY

The Sendmail mail delivery subsystem is vulnerable to multiple local
attacks that may lead to information loss, information leaks and complete
mail system compromise.

DETAILS

Vulnerable systems:
The mail system privileges compromise affects Sendmail 8.12.0. Other
problems affect all versions up to 8.12.0.

Immune systems:
Sendmail version 8.12.1

Vulnerability 1: Mail System Compromise
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 bulletproof - it is intended
to parse trusted content or un-trusted content, but run with no extra
privileges. Razor has 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 zero. Again, the queue file processing algorithm is not
bulletproof. 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 occurs 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:
Razor has 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
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
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 have not 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 malicious 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.

  - Additional 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."

ADDITIONAL INFORMATION

The information has been provided by <mailto:lcamtuf@echelon.pl> Michal
Zalewski.

========================================

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.

Relevant Pages