The Sendmail, Inc. security advisory template will be used for all
security notifications, regardless of whether a patch is required or a
workaround is provided to the customer.

The parenthetical references are described in the Notes section.  Each
section of the advisory contains a description of that section with
examples, both of which will not be in the final advisory.  The examples
are purposefully kept short to save space.  Actual advisories may be
longer, but they must be concise.

All Sendmail advisories will be done in plain text and PGP signed using
the Security Officer PGP key available from:

http://www.sendmail.com/security/security-officer.asc

This template is subject to change without notice.

=============================================================================
Sendmail-SA-YYYYMM-##  (1)                                  Security Advisory
                                                               Sendmail, Inc.

Topic:          One line description of the issue  (2)

Class:          Class  (3)
Severity:       Severity  (4)
Announced:      YYYY-MM-DD HH:MM ZZZ  (5)
Revised:        YYYY-MM-DD HH:MM ZZZ  (6)
Credits:        List problem reporter(s)  (7)
Affects:        List affected products/versions  (8)
Resolved:       List fixed versions  (9)

For general information regarding Sendmail, Inc. Security Advisories,
including descriptions of the fields above, other security advisories,
and the following sections, please visit <http://www.sendmail.com/security/>.


I. Background

    The Background section describes the affected program and what it
    is used for.  It does not discuss the problem itself, but could be
    used to discuss the functionality in the program where the problem
    exists.  An example might be:

      Sendmail Switch includes the sendmail MTA which is used to route
      mail into and out of an organization using SMTP.  That protocol
      uses timeouts to prevent resource starvation on the server.


II. Problem Description

    The Problem Description section explains the security hole. This can
    include information on flawed code, or even how the program may be
    maliciously used to open a security hole.  An example might be:

      The implementation of SMTP protocol timeouts in sendmail used UNIX
      signals, which can inadvertently interrupt code flow leaving a
      variable in an inconsistent state.


III. Impact

    The Impact section describes what type of impact the problem may
    have on a system.  For example, this can be anything from a denial
    of service attack, to extra privileges available to users, or even
    giving the attacker superuser access.  For example:

      By taking advantage of a race condition in the signaling used
      to implement timeouts, a remote attacker may be able to exploit
      the problem using a timed attack.  If successfully exploited,
      the attacker may be able to modify files writable by sendmail's
      RunAsUser or execute commands as that user.


IV. Workaround

    The Workaround section offers a feasible workaround to system
    administrators who may be incapable of upgrading the system. This
    may be due to time constraints, network availability, or a slew of
    other reasons.  Regardless, security is not to be taken lightly, and
    an affected system needs to be patched or the workaround needs to
    be implemented.  If there is no workaround available, that will be
    stated here.  For example:

      You can work around this problem by disabling all SMTP timeouts.
      However, doing so may leave your system vulnerable to resource
      starvation.

    or another example:

      No workaround is available for this problem.

V. Solution

    The Solution section offers instructions on patching the affected
    product(s). This is a step by step description, tested and verified
    method for getting a product patched and working securely.  This
    section is likely to be the longest in the advisory as different
    instructions may be needed for different products.  A shortened
    example:

      Login to support system at <http://www.sendmail.com/customerlogin/>
      to download the 3.1.8 cumulative patch.  Apply the Switch 3.1.8
      patch per instructions in the included README.txt.


VI. References

    The References section usually offers sources of other information.
    This can included web URLs, books, mailing lists, and newsgroups.
    For example:

      CVE: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0058

      Sendmail KB: https://www.sendmail.com/cfusion/CFIDE/kb_doc.cfm?kb_id=S10621

      FAQ: http://www.sendmail.com/security/SA-200604-01/faq.shtml


VII. Revision Details

    The Revision Details section contains a list of changes made to the
    advisory since its initial release.  Each revision will be listed
    separately so readers can see the revision history.  For example:

      2006-04-16 12:45 PDT:  Added a new timeout work around.
                             Correct patch download instructions.

      2006-04-17 14:30 PDT:  Added CVE reference.


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

Notes
-----

(1) Each advisory will have a unique ID made up of "Sendmail-SA-"
    followed by the four digit year and the two digit month followed
    by a counter.  The counter resets each month.  Examples include
    "Sendmail-SA-200604-01" and "Sendmail-SA-200611-10", the latter
    being the tenth advisory for November, 2006.


(2) The Topic field indicates exactly what the problem is. It is
    an introduction to the current security advisory and identifies
    the program with the vulnerability.  For example:

    Topic: Remote privilege escalation in sendmail MTA


(3) The Class field uses one of the following values to describe the type
    of security problem.  Each type is prefixed with "Local" or "Remote"
    to indicate whether the attack can be performed by a local user or
    a remote user (e.g., "Local Denial of Service" or "Remote Policy
    Bypass").  A "Remote" attack assumes the ability for "Local" users
    to attack the service as well.

    Denial of Service
       - Interrupting, inhibiting, or disabling of a service by triggering a
         bug in the service or exhausting resources needed to provide that
         service.

    Policy Bypass
       - The ability to bypass access restrictions on the service.  For
         example, injecting dangerous content that policy should block or
         promiscuous relaying of mail.

    Information leak
       - Providing information to an attacker which would normally not be
         available.  Examples include revealing the contents of files,
         hidden fields in databases, or traffic/logs for other users of
         that service.

    Privilege escalation
       - A condition which gives an attacker privileges above and beyond
         those to which the user is entitled.  Examples include the ability
         to create arbitrary files, influence content of files, start and
         stop services, go beyond the user or service's resource limits, or
         becoming another user, including potentially root.

    Code execution
       - The ability for a remote entity to execute arbitrary code on the
         server that is outside the functionality provided by the service.
         For example, using the SMTP ETRN command to cause a queue run to
         occur is not considered "remote code execution" as that is the
         expected behavior of the ETRN command.


(4) The Severity field uses one of the following values to describe the
    severity of the problem.

    Critical
       - An easily exploitable condition which has serious end user
         consequences (i.e., public exploit available or relatively easy to
         create an exploit).

    High
       - An exploitable condition which has serious end user consequences
         but is not easily exploitable (i.e., no known exploits and
         difficult to produce an exploit).

    Medium
       - An exploitable condition which has moderate end user consequences
         but doesn't present a clear and present danger for end users.

    Low
       - A condition which could almost be considered an annoyance, does
         not have a serious impact on end users, and can easily be worked
         around.


(5) The Announced field reflects the date the security advisory was
    published, or announced to the world. This means the Sendmail
    security team has verified that the problem does exist and, if
    applicable, that a patch has been made available.  For example:

    Announced: 2006-04-17 08:00 PDT


(6) The Revised field reflects the date the advisory was last revised
    with new information or corrections.  Additionally, a change log for
    each revision will be put in section VIII.  This field only exists
    in advisories which have been revised since the initial creation.
    For example:

    Revised: 2006-04-17 14:30 PDT


(7) The Credits field gives credit to the individual(s) or
    organization(s) who noticed the vulnerability and reported it.
    For example:

    Credits: Rob Davies from the Internet Security Union
             John Simpson from Worcester Polytechnic Institute


(8) The Affects field explains which versions of our products are
    affected by this vulnerability.  For example:

    Affects: Sendmail Pro (all versions)
             Sendmail Switch 2.X and 3.X (up to and including 3.1.8)
             Sendmail Sentrion 1.0-1.5


(9) The Resolved field indicates the versions which include the
    correction.  For example:

    Resolved: Sendmail Switch 3.1.9
              Sendmail Sentrion 1.5.1


$Revision: 1.11 $ $Date: 2006/09/09 00:16:38 $