A very good paper was recently written on these types of bugs which can be
found here:
http://razor.bindview.com/publish/papers/signals.txt
AFAIK OpenBSD was the first ones to release patches for this bug...
----- Original Message -----
From: "Kurth Bemis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 01, 2001 1:20 PM
Subject: Oops,I guess Sendmail wasn't secure after all... (fwd)
>
> got this off o the qmail list today. might me an intresting read for all
> you sendmail die hards :-)
>
> ~kurth
>
> Kurth Bemis
> Senior Network Admin/Owner: USAExpress.net
> Owner: Ozone Computer
>
> http://kurth.hardcrypto.com
> PGP Key Avail.
> ---------------------------------------------------------------------
> Uh!.....Uh!.....Uh!....."I'm done with this."...Out the window
>
> ---------- Forwarded message ----------
> Date: Fri, 1 Jun 2001 12:07:36 -0400
> From: Dave Sill <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Subject: Oops,I guess Sendmail wasn't secure after all...
>
> From: Gregory Neil Shapiro <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: sendmail 8.11.4 and 8.12.0.Beta10 available
>
> 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.
>
> Also from bugtraq:
>
> From: [EMAIL PROTECTED] (Michal Zalewski)
> Subject: Unsafe Signal Handling in Sendmail
>
> RAZOR advisory: Unsafe Signal Handling in Sendmail
>
> Issue Date: May 28, 2001
> Contact: Michal Zalewski <[EMAIL PROTECTED]>
>
> 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).
>
> ...
>
> References:
>
> For more information on signal delivery race conditions, please
> refer to RAZOR whitepaper at:
>
> http://razor.bindview.com/publish/papers/signals.txt
>
> Anyone want to takes bets on whether qmail has unsafe signal handlers?
>
> -Dave
>
>
> **********************************************************
> To unsubscribe from this list, send mail to
> [EMAIL PROTECTED] with the following text in the
> *body* (*not* the subject line) of the letter:
> unsubscribe gnhlug
> **********************************************************
>
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
