6554738 2001-05-28 18:16 -0400 /108 rader/ Michal Zalewski <lcamtuf@bos.bindview.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-05-29 09:19 av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Mottagare: Bugtraq (import) <17189>
Ärende: Unsafe Signal Handling in Sendmail
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@bos.bindview.com>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0105281810350.18807-100000@nimue.bos.bindview.com>
RAZOR advisory: Unsafe Signal Handling in Sendmail
Issue Date: May 28, 2001
Contact: Michal Zalewski <lcamtuf@razor.bindview.com>
Topic:
Sendmail signal handlers used for dealing with specific signals are
vulnerable to numerous race conditions.
Affected Systems:
Any systems running sendmail (tested on sendmail 8.11.0,
8.12.0-Beta5)
Details:
Sendmail signal handlers used for dealing with specific signals
(SIGINT, SIGTERM, etc) are vulnerable to numerous race conditions,
including handler re-entry, interrupting non-reentrant libc
functions and entering them again from the handler (see
"References" for more details on this family of
vulnerabilities). This set of vulnerabilities exist because of
unsafe library function calls from signal handlers (malloc, free,
syslog, operations on global buffers, etc).
As sendmail is setuid root and can be invoked by user, and -
moreover
- keeps running with root privileges almost all the time, there is no
problem with delivering signals at a specific moment.
It is worth mentioning that not only sendmail is suspectible to
have this kind of problems. Moreover, in some situations, unsafe
signal handlers can be even exploited remotely, by delivering
SIGURG over TCP stream (OOB message). Whenever SIGURG is handled
in remote daemons in verbose way using unsafe functions, this is
an exploitable condition. Note, sendmail is not vulnerable to
this.
Impact:
One of the attack paths we can see is delivering SIGTERM while
sendmail is working in 'verbose debugging' mode (-d
switch). SIGTERM handler works less or more this way:
- ...
- syslog(...) call with user-dependent information
- ...
- fclose(...)
- free(...)
- free(...)
- ...
- exit(...)
This is important that syslog() function effectively calls
malloc() code to allocate a temporary buffer. As exactly the same
handler is used for SIGINT, and there is no re-entry protection in
this handler, we can reach appropriate (usually the second) free()
call, and deliver SIGTERM. Then, already free()d memory will be
overwritten with user-dependent data from syslog() buffer, as new
memory chunk would fit in the place of free()d buffers. Then,
duplicate free() attempt on the memory region containing
user-dependent data will be performed, which would lead to program
execution path compromise. This is a difficult race, but can be
attempted numerous times.
Note that avoiding re-entry into signal handler is not the only
thing that has to be done. Other possibilities include
e.g. re-entering functions like malloc() - in this case, signal
has to be delivered only once, in the middle of malloc()
call. That would lead to heap corruption. Any functions that are
not reentrant should be protected in a special way or not used at
all in signal handlers.
Vendor response / fix info:
From sendmail-security@sendmail.org:
We agree with Michal Zalewski's comments regarding the possibility
of heap corruption due to signal delivery. We do not believe the
heap corruption to be easily exploitable due to the complexity
involved with timing and the little control the user has over the
contents of memory in the signal handler. This is different than
buffer overflows attacks which occur on the stack and allow users
to insert specific instructions at a known location. At the
present time, there is no proof that this is exploitable as there
are no known exploits.
However, the corruption could crash the process and we have taken
measures to reduce this possibility in 8.11.4. We have eliminated
the ability to reenter a signal handler making the attack
discussed above impossible. Additionally, sendmail 8.12 will no
longer require a set-user-id root binary.
Note that this attack can only be used by a process started by the
user and therefore can not be used as a denial of service attack
and also is not remotely exploitable. The information regarding
remote attacks and SIGURG does not apply to sendmail as SMTP does
not use out of band messages.
References:
For more information on signal delivery race conditions, please
refer to RAZOR whitepaper at:
http://razor.bindview.com/publish/papers/signals.txt
(6554738) /Michal Zalewski <lcamtuf@bos.bindview.com>/(Ombruten)
6554798 2001-05-29 00:10 +0200 /156 rader/ Jonas Eriksson <je@sekure.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-05-29 09:35 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17190>
Ärende: sendmail 8.11.4 and 8.12.0.Beta10 available (fwd)
------------------------------------------------------------
From: Jonas Eriksson <je@sekure.net>
To: bugtraq@securityfocus.com
Message-ID: <Pine.BSO.4.21.0105290008070.27905-100000@birdie.sekure.net>
---------- Forwarded message ----------
Date: Mon, 28 May 2001 09:11:15 -0700
From: Gregory Neil Shapiro <sendmail+gshapiro@sendmail.org>
To: sendmail-announce@sendmail.org
Subject: sendmail 8.11.4 and 8.12.0.Beta10 available
-----BEGIN PGP SIGNED MESSAGE-----
Sendmail, Inc., and the Sendmail Consortium announce the availability
of sendmail 8.11.4 and 8.12.0.Beta10.
8.11.4 revamps signal handling within the MTA in order to reduce the
likelihood of a race condition that can lead to heap corruption as
described in Michal Zalewski's advisory. The problems discussed in
the advisory are not currently known to be exploitable but we
recommend upgrading to 8.11.4 in case a method is found to exploit
the signal handling race condition. 8.11.4 also fixes other bugs
found since the release of 8.11.3.
8.12.0.Beta10 includes the changes in signal handling from 8.11.4.
Moreover, there is a significant change compared to earlier beta
versions: by default sendmail is installed as a set-group-id binary;
a set-user-id root binary will be only installed if the proper
target is selected (see sendmail/SECURITY). Beta10 fixes also a
few bugs, especially possible core dumps during queue runs and in a
milter application (using smfi_chgheader), possible rejection of
messages due to an uninitialized variable, and omitting queue runs
if queue groups are used and the total number of queue runners is
restricted to less than the sum of the individual queue runners.
Please send bug reports to sendmail-bugs@sendmail.org and general
feedback to sendmail@sendmail.org.
The versions can be found at:
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.11.4.tar.gz
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.11.4.tar.Z
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.11.4.tar.sig
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.0.Beta10.tar.gz
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.0.Beta10.tar.Z
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.12.0.Beta10.tar.sig
MD5 signatures:
5e224eeb0aab63b7c178728ae42f26a5 sendmail.8.11.4.tar.gz
45b2d3694a4fa952739aba82a2df3522 sendmail.8.11.4.tar.Z
d2cd6011a6b395ea07091414be869152 sendmail.8.11.4.tar.sig
6f8e398b04da5ccfca6bd6f9f52de28e sendmail.8.12.0.Beta10.tar.gz
85d73a1ab711b23f4afb3cb6048c0624 sendmail.8.12.0.Beta10.tar.Z
d2631e7b3275a9fba3c3666bad62afa5 sendmail.8.12.0.Beta10.tar.sig
You need either the gzip'ed version (.gz) or the compressed version
(.Z). The .sig files contain the PGP signature of the tar files
(after uncompressing). The PGP signatures were created using the
Sendmail Signing Key/2001, available on the web site
(http://www.sendmail.org/) or on the public key servers.
Since sendmail 8.11 and later includes hooks to cryptography, the
following information from OpenSSL applies to sendmail as well.
PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG
CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST
COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS
ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS
PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST
EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR
OR OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO
ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS
ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT
IS YOUR RESPONSIBILITY.
8.11.4/8.11.4 2001/05/28
Clean up signal handling routines to reduce the chances of heap
corruption and other potential race conditions.
Terminating and restarting the daemon may not be
instantaneous due to this change. Also, non-root users can
no longer send out-of-band signals. Problem reported by
Michal Zalewski of BindView.
If LogLevel is greater than 9 and SASL fails to negotiate an
encryption layer, avoid core dump logging the encryption
strength. Problem noted by Miroslav Zubcic of Crol.
If a server offers "AUTH=" and "AUTH " and the list of mechanisms is
different in those two lines, sendmail might not have
recognized (and used) all of the offered mechanisms.
Fix an IP address lookup problem on Solaris 2.0 - 2.3. Patch
from Kenji Miyake.
This time, really don't use the .. directory when expanding
QueueDirectory wildcards.
If a process is interrupted while closing a map, don't try to close
the same map again while exiting.
Allow local mailers (F=l) to contact remote hosts (e.g., via
LMTP). Problem noted by Norbert Klasen of the University
of Tuebingen.
If Timeout.QueueReturn was set to a value less the time it took
to write a new queue file (e.g., 0 seconds), the bounce
message would be lost. Problem noted by Lorraine L Goff of
Oklahoma State University.
Pass map argument vector into map rewriting engine for the regex
and prog map types. Problem noted by Stephen Gildea of
InTouch Systems, Inc.
When closing an LDAP map due to a temporary error, close all of the
other LDAP maps which share the original map's connection
to the LDAP server. Patch from Victor Duchovni of
Morgan Stanley.
To detect changes of NDBM aliases files check the timestamp of the
.pag file instead of the .dir file. Problem noted by Neil
Rickert of Northern Illinois University.
Don't treat temporary hesiod lookup failures as permanent. Patch
from Werner Wiethege.
If ClientPortOptions is set, make sure to create the outgoing socket
with the family set in that option. Patch from Sean Farley.
Avoid a segmentation fault trying to dereference a NULL pointer
when logging a MaxHopCount exceeded error with an empty
recipient list. Problem noted by Chris Adams of HiWAAY
Internet Services.
Fix DSN for "Too many hops" bounces. Problem noticed by Ulrich
Windl of the Universitaet Regensburg.
Fix DSN for "mail loops back to me" bounces. Problem noticed by
Kari Hurtta of the Finnish Meteorological Institute.
Portability:
OpenBSD has a broken setreuid() implementation.
CONFIG: Undo change from 8.11.1: change 501 SMTP reply code back
to 553 since it is allowed by DRUMS.
CONFIG: Add OSTYPE(freebsd4) for FreeBSD 4.X.
DEVTOOLS: install.sh did not properly handle paths in the source
file name argument. Noted by Kari Hurtta of the Finnish
Meteorological Institute.
DEVTOOLS: Add FAST_PID_RECYCLE to compile time options for OpenBSD
since it generates random process ids.
PRALIASES: Add back adaptive algorithm to deal with different endings
of entries in the database (with/without trailing '\0').
Patch from John Beck of Sun Microsystems.
New Files:
cf/ostype/freebsd4.m4
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface
Charset: noconv
iQCVAwUBOxJ4WnxLZ22gDhVjAQEIEQP+JItPxBNK++A3csI0GQG9i63fhaOSc4d0
1ivTU7Xx9JB7rC2LFIChsrDmCVPYrT6c9TKTpM8SdPjN2D8IVBzMkfTcyzJ7DQQF
HNvqwl+aZ7h6lw06mu8X0+msNlWEov3Wa/1vGoh2bHL5YR4gsnVz6tQGpf1iCBi3
eI1vXU/vtCs=
=DHLv
-----END PGP SIGNATURE-----
(6554798) /Jonas Eriksson <je@sekure.net>/(Ombruten)