Note: This is an archival copy of Security Sun Alert 200463 as previously published on http://sunsolve.sun.com.
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000341.1.
Article ID : 1000341.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2006-09-26
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

Sun Cobalt sendmail(8) Security Issue Involving Signal Handling Daemon



Category
Security

Release Phase
Resolved

Product
Sun Cobalt RaQ XTR Server
Sun Cobalt RaQ 4 Server
Sun Cobalt RaQ 550 Server

Bug Id
17084, 17085, 17086

Date of Workaround Release
25-APR-2006

Date of Resolved Release
27-SEP-2006

Impact

A local or remote unprivileged user may be able to execute arbitrary code with elevated privileges or cause a Denial of Service (DoS) condition on a Sun Cobalt system due to a security vulnerability in the sendmail(8) daemon involving signal handling.

This issue is referenced in the following documents:

CERT VU#834865 http://www.kb.cert.org/vuls/id/834865 which is referenced in CERT Technical Cyber Security Alert TA06-081A: http://www.us-cert.gov/cas/techalerts/TA06-081A.html


Contributing Factors

This issue can occur in the following releases:

  • RaQ4 with sendmail versions 8.10.2-C4stackguard or earlier
  • RaQ550 with sendmail versions 8.11.6-1C6stackguard or earlier
  • RaQXTR with sendmail versions 8.11.6-1C6stackguard or earlier

with the sendmail(8) service enabled.

The sendmail package version can be determined by running the following command:

    # rpm -qa | grep -i sendmail
    sendmail-8.11.6-1C6stackguard

To determine whether sendmail(8) is enabled for the various run levels, the following command can be used:

    # /sbin/chkconfig --list sendmail
    sendmail 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Symptoms

There are no reliable symptoms that would indicate this issue has been exploited to execute arbitrary commands with elevated privileges on a system. The symptoms of the Denial of Service would be the sendmail daemon no longer running.


Workaround

To work around the described issue, sites may wish to block access to the affected service from untrusted networks such as the Internet, or disable the sendmail daemon where possible. Use a firewall or other packet-filtering technology to block the appropriate network ports. Consult your vendor or your firewall documentation for detailed instructions on how to configure the ports.

The following command can be used to temporarily disable sendmail for all run levels:

    # /sbin/chkconfig --del sendmail

Resolution

This issue is addressed in the following releases:



Modification History
Date: 27-SEP-2006

27-Sep-2006:

  • Updated Resolution section
  • State: Resolved











Attachments
This solution has no attachment