TUCoPS :: SunOS/Solaris

TUCoPS :: SunOS/Solaris :: n-148.txt
Sun Security Issue Involving the Solaris sadmind(1M) Daemon (CIAC N-148)

__________________________________________________________

The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________

INFORMATION BULLETIN

Sun Security Issue Involving the Solaris sadmind(1M) Daemon
[Sun Alert ID: 56740]

September 16, 2003 18:00 GMT Number N-148
______________________________________________________________________________
PROBLEM: Forged AUTH_SYS credentials might be accepted by sadmind(1M),
thus allowing privilege escalation.
PLATFORM: SPARC & x86: Solaris 7, 8, 9, Trusted Solaris 7, 8
DAMAGE: A local or remote unprivileged user may be able to execute
arbitrary commands.
SOLUTION: Change configuration for authentication.
______________________________________________________________________________
VULNERABILITY The risk is MEDIUM. The attacker has to already have an account
ASSESSMENT: on the system.
______________________________________________________________________________
LINKS:
CIAC BULLETIN: http://www.ciac.org/ciac/bulletins/n-148.shtml
ORIGINAL BULLETIN:
http://www.sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert
%2F56740&zone_32=category%3Asecurity
______________________________________________________________________________
[***** Start Sun Alert ID: 56740 *****]

Sun(sm) Alert Notification
Sun Alert ID: 56740
Synopsis: Security Issue Involving the Solaris sadmind(1M) Daemon
Category: Security
Product: Solaris
BugIDs: 4079984
Avoidance: Workaround
State: Resolved
Date Released: 15-Sep-2003
Date Closed: 15-Sep-2003
Date Modified:

1. Impact
A local or remote unprivileged user may be able to execute arbitrary commands
with the permissions of the sadmind(1M) daemon on Solaris systems which have
sadmind(1M) enabled in inetd.conf(4). The sadmind(1M) daemon normally runs
with "root" (uid 0) privileges. If the sadmind(1M) daemon is utilizing the
default security level authentication mechanism of AUTH_SYS
(see secure_rpc(3NSL)), users may be able to forge AUTH_SYS credentials as
described in the sadmind(1M) man page.

This issue is not new and patches are not planned at this time. An exploit has
been discovered in the wild and this Sun Alert is to raise awareness of the
default sadmind(1M) configuration on Solaris systems.

Sun acknowledges, with thanks, iDefense for working with us on this issue.

2. Contributing Factors
This issue can occur in the following releases:

SPARC Platform

Solaris 7 and Trusted Solaris 7
Solaris 8 and Trusted Solaris 8
Solaris 9
x86 Platform

Solaris 7 and Trusted Solaris 7
Solaris 8 and Trusted Solaris 8
Solaris 9
Sites which have sadmind(1M) enabled in inetd.conf(4) with strong authentication
(-S 2) are not affected by this issue.

To determine if sadmind(1M) is enabled on the system, the following command can
be run:

$ grep sadmind /etc/inet/inetd.conf
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind
This shows the sadmind(1M) daemon enabled with the default security level
authentication mechanism.

Note: Previous releases of Solaris and Trusted Solaris which shipped with
sadmind(1M) included the same default sadmind(1M) entry in the inetd.conf(4)
file.

3. Symptoms
If the described issue occurs, the sadmind(1M) entry in the inetd.conf(4) will
be enabled (not commented out) and will not be configured to use strong
(AUTH_DES -- see secure_rpc(3NSL)) authentication.

The following example shows a system which is utilizing weak (AUTH_SYS)
authentication and is affected by this issue:

$ grep sadmind /etc/inet/inetd.conf
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind
The following example shows a system which is utilizing strong (AUTH_DES)
authentication and is not affected by this issue:

$ grep sadmind /etc/inet/inetd.conf
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2
The following example shows a system which is not utilizing sadmind(1M) as the
sadmind entry has been commented out from the inetd.conf(4) file and is not
affected by this issue:

$ grep sadmind /etc/inet/inetd.conf
#100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind
Solution Summary Top

4. Relief/Workaround
To workaround this issue, either disable the sadmind(1M) on the systems or
enable strong (AUTH_DES) authentication by adding "-S 2" to the sadmind(1M)
entry of the inetd.conf(4) file.

To disable sadmind(1M) on a Solaris system, do the following:

1. Edit the "/etc/inetd.conf" file and comment out the following line by
adding the "#" symbol to the beginning of the line as follows:

#100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind
2. Tell the inetd(1M) process to reread the newly modified "/etc/inetd.conf"
file by sending it a hangup signal, SIGHUP:

# /usr/bin/pkill -HUP inetd
To enable strong (AUTH_DES) authentication for sadmind(1M) on a Solaris system,
do the following:

1. Edit the "/etc/inetd.conf" file and append "-S 2" to the end of the sadmind
line as follows:

100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2
2. Tell the inetd(1M) process to reread the newly modified "/etc/inetd.conf"
file by sending it a hangup signal, SIGHUP:

# /usr/bin/pkill -HUP inetd
5. Resolution
Please see the Workaround section above for the resolution to this issue.

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.

[***** End Sun Alert ID: 56740 *****]
_______________________________________________________________________________

CIAC wishes to acknowledge the contributions of Sun Microsystems for the
information contained in this bulletin.
_______________________________________________________________________________

CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 925-422-8193 (7x24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)

N-138: Red Hat Updated Sendmail packages fix vulnerability
N-139: Red Hat Updated SSL Certificate for access to 'up2date'
N-140: Sun Linux Vulnerability in VNC Package may allow local or remote unauthorized access
N-141: Timing based attack vulnerabilities in the JAVA Secure Socket Extension
N-142: Microsoft Word Macros Vulnerability
N-143: Microsoft WordPerfect Converter Buffer Overrun Vulnerability
N-144: Microsoft Visual Basic Buffer Overrun Vulnerability
N-145: Microsoft Access Snapshot View Buffer Overrun Vulnerability
N-146: Apache 2.0.47 Release Fixes Security Vulnerabilities
N-147: Hewlett Packard Potential Security Vulnerability B.11.11 DCE