Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2006.0419 -- [Solaris]
A Security Vulnerability in sendmail(1M) May Allow a Denial
of Service (DoS) To Occur
23 August 2006
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: Sendmail
Publisher: Sun Microsystems
Operating System: Solaris 8, 9 and 10
Impact: Denial of Service
Access: Remote/Unauthenticated
CVE Names: CVE-2006-1173
Ref: AL-2006.0048
Revision History: August 23 2006: Updated Contributing Factors and
Resolution sections
August 21 2006: Updated workaround section
August 4 2006: Sun released updates to Contributing
Factors and Resolution sections
June 22 2006: Mitigation section updated
June 16 2006: Initial Release
- --------------------------BEGIN INCLUDED TEXT--------------------
Sun(sm) Alert Notification
* Sun Alert ID: 102460
* Synopsis: A Security Vulnerability in sendmail(1M) Versions Prior
to 8.13.7 May Allow a Denial of Service (DoS) To Occur
* Category: Security
* Product: Solaris 9 Operating System, Solaris 10 Operating System,
Solaris 8 Operating System
* BugIDs: 6424201
* Avoidance: Workaround, Patch
* State: Workaround
* Date Released: 14-Jun-2006
* Date Closed:
* Date Modified: 20-Jun-2006, 10-Jul-2006, 21-Jul-2006, 26-Jul-2006,
02-Aug-2006, 16-Aug-2006, 21-Aug-2006
1. Impact
On hosts where sendmail(1M) is configured to accept incoming mail, a
local or remote unprivileged user may be able to prevent sendmail from
successfully delivering queued messages, resulting in a Denial of
Service (DoS) of the sendmail delivery mechanism.
On hosts which do not accept remote incoming mail, but make use of
sendmail(1M) to deliver messages to other hosts and users, a local
unprivileged user may be able to prevent sendmail from delivering
queued messages, again resulting in a Denial of Service (DoS) of the
sendmail delivery mechanism.
If either of the two issues above are exploited, an additional Denial
of Service (DoS) to the system may occur if sendmail(1M) is configured
to write unique core files to disk and to attempt to flush the
delivery queue regularly. Each attempt to flush the delivery queue
will result in a new core file being written to disk, eventually
consuming all available space.
This issue is referenced in the following documents:
CVE-2006-1173 at
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1173
CERT VU#146718 at http://www.kb.cert.org/vuls/id/146718
2. Contributing Factors
This issue can occur in the following releases:
SPARC Platform
* Solaris 8 without patch 110615-15
* Solaris 9 without patch 113575-07
* Solaris 10 without patch 122856-02
x86 Platform
* Solaris 8 without patch 110616-15
* Solaris 9
* Solaris 10 without patch 122857-03
Notes:
1. The current Solaris 8 sendmail patches (110615-14 for SPARC and
110616-14 for x86) update sendmail to version 8.11.7p2+Sun. This
version of sendmail is affected by this vulnerability.
The Solaris 8 patches which will address this vulnerability will
update sendmail to version 8.11.7p3+Sun. This is a minor change to
this version of sendmail, however, these are the only patches which
are required to address this vulnerability in Solaris 8.
The Solaris 9 and 10 patches which address this issue will update
sendmail directly to version 8.13.7+Sun.
2. This issue only affects systems which have sendmail(1M) enabled, or
which use sendmail to deliver messages.
3. Sendmail versions prior to 8.13.7 are impacted by this issue.
A) To determine if sendmail(1M) is running on the system and its
version number, the mconnect(1) command can be used, as in the
following example:
$ /usr/bin/mconnect
connecting to host localhost (127.0.0.1), port 25
connection open
220 an.example.com ESMTP Sendmail 8.13.5+Sun/8.13.5;
Mon, 20 Mar 2006 17:07:57 GMT
quit
221 2.0.0 an.example.com closing connection
If sendmail is not running on the system, the mconnect(1) command will
report the following:
$ /usr/bin/mconnect
connecting to host localhost (127.0.0.1), port 25
connect: Connection refused
To determine if sendmail(1M) is configured for use in delivering
messages, the presence of the `sendmail.cf' file can be checked, using
a command such as the following:
$ file /etc/mail/sendmail.cf
/etc/mail/sendmail.cf: English text
To determine if there are currently messages in sendmail's queue which
may be affected by this issue, the following commands can be used with
the default sendmail(1M) configuration (the second command is
available on Solaris 9 and later only):
# mailq
/var/spool/mqueue is empty
Total requests: 0
# mailq -Ac
/var/spool/clientmqueue is empty
Total requests: 0
B) To determine if the system is vulnerable to the additional issue of
disk space consumption, check whether sendmail(1M) is configured to
create unique core dumps using the coreadm(1M) command to check the
global and per-process core dump settings which affect the sendmail
processes:
$ coreadm | grep global
global core file pattern: /var/cores/core.%f.%p
global core file content: default
global core dumps: enabled
global setid core dumps: disabled
global core dump logging: disabled
# coreadm `pgrep sendmail`
109584: core.%f.%p default
109586: core default
3. Symptoms
If this issue has been exploited to cause a Denial of Service(DoS),
some messages may remain in the delivery queue indefinitely, and will
not be delivered to their destinations. Note that if this issue
occurs, sendmail will continue to receive messages from remote hosts
and will successfully deliver messages which are not deferred into the
delivery queue.
If sendmail is configured to save unique core dumps, these will be
stored at a path that depends on the configuration set with
coreadm(1M) and will occupy an increasing share of the disk space.
4. Relief/Workaround
To prevent the disruption of the sendmail(1M) delivery mechanism, the
'ForkEachJob' option can be set, causing sendmail to deliver each
message in its own process, preventing any one message from disrupting
the delivery of other messages. However, this may have an impact on
the performance of the delivery process.
This option can be set by adding the following line to the *.mc files
used to generate the "/etc/mail/sendmail.cf" and "/etc/mail/submit.cf"
(if present) files:
define(`confSEPARATE_PROC',`true')dnl
The *.mc files are located in "/usr/lib/mail/cf" for Solaris 8 and 9,
and "/etc/mail/cf/cf" for Solaris 10.
Generate the new *.cf files from these revised *.mc files and copy to
"/etc/mail/sendmail.cf" and "/etc/mail/submit.cf" as required. Please
refer to "/usr/lib/mail/README" for additional information on how to
use the *.mc files.
Restart sendmail once the modifications have been performed, as
follows:
Solaris 10:
# svcadm restart sendmail
Solaris 8, 9:
# /etc/init.d/sendmail stop
# /etc/init.d/sendmail start
To prevent sendmail(1M) from filling up the disk, it can be configured
using the coreadm(1M) command to write statically named core files.
This should be applied to both the global core file pattern (if
enabled) and the per-process core file pattern.
For example, to disable global core files:
# coreadm -d global
and to make sendmail core dump filenames static until the sendmail
service is restarted:
# coreadm -p core.%f $(pgrep sendmail)
A preliminary T-Patch is available for the following release from
http://sunsolve.sun.com/tpatches:
x86 Platform
* Solaris 9 T-patch T114137-06
This document refers to one or more preliminary temporary patches
(T-Patches) which are designed to address the concerns identified
herein. Sun has limited experience with these patches due to their
preliminary nature. As such, you should only install the patches on
systems meeting the configurations described above. Sun may release
full patches at a later date, however, Sun is under no obligation
whatsoever to create, release, or distribute any such patch.
5. Resolution
This issue is addressed in the following releases:
SPARC Platform
* Solaris 8 with patch 110615-15 or later
* Solaris 9 with patch 113575-07 or later
* Solaris 10 with patch 122856-02 or later
x86 Platform
* Solaris 8 with patch 110616-15 or later
* Solaris 10 with patch 122857-03 or later
A final resolution is pending completion.
Change History
20-Jun-2006:
* Updated Relief/Workaround section
10-Jul-2006:
* Updated Relief/Workaround section
21-Jul-2006:
* Updated Contributing Factors and Resolution sections
26-Jul-2006:
* Updated Contributing Factors and Relief/Workaround sections
02-Aug-2006:
* Updated Contributing Factors and Resolution sections
16-Aug-2006:
* Updated Relief/Workaround section
21-Aug-2006:
* Updated Contributing Factors and Resolution sections
This Sun Alert notification is being provided to you on an "AS IS"
basis. This Sun Alert notification may contain information provided by
third parties. The issues described in this Sun Alert notification may
or may not impact your system(s). Sun makes no representations,
warranties, or guarantees as to the information contained herein. ANY
AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT, ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENT
YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISE
OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN.
This Sun Alert notification contains Sun proprietary and confidential
information. It is being provided to you pursuant to the provisions of
your agreement to purchase services from Sun, or, if you do not have
such an agreement, the Sun.com Terms of Use. This Sun Alert
notification may only be used for the purposes contemplated by these
agreements.
Copyright 2000-2006 Sun Microsystems, Inc., 4150 Network Circle, Santa
Clara, CA 95054 U.S.A. All rights reserved
- --------------------------END INCLUDED TEXT--------------------
You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.
NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/render.html?cid=1980
If you believe that your computer system has been compromised or attacked in
any way, we encourage you to let us know by completing the secure National IT
Incident Reporting Form at:
http://www.auscert.org.au/render.html?it=3192
===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967
iQCVAwUBROvSyih9+71yA2DNAQJ7KQP+OMzFqGIdWZCX0bFbaufMKbXLzeLF2ivz
lBDsGoFQGeI/sl4kEG78IiSNYac+h2QpfLNq/rfDNrhjy5jguEzFef2OH9pUmcKU
bPsBYQYMSa4EyXYJY/OTdeatA+x+MH3ULdYc0Brrjo4UpX05tuE9PgWr7NCBUchp
clkkboDo7M4=
=HkxP
-----END PGP SIGNATURE-----