7211267 2001-10-01 11:57 -0400 /204 rader/ Michal Zalewski <lcamtuf@echelon.pl>
Sänt av: joel@lysator.liu.se
Importerad: 2001-10-01 21:12 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: sendmail-security@sendmail.org
Mottagare: Bugtraq (import) <19320>
Ärende: RAZOR advisory: multiple Sendmail vulnerabilities
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@echelon.pl>
To: bugtraq@securityfocus.com
Cc: sendmail-security@sendmail.org
Message-ID: <Pine.LNX.4.21.0110011139530.737-100000@nimue.bos.bindview.com>
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:
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.
(7211267) /Michal Zalewski <lcamtuf@echelon.pl>/(Ombruten)