[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

UNIRAS Brief - 130/04 - Sun Security Advisory



 
-----BEGIN PGP SIGNED MESSAGE-----

- ----------------------------------------------------------------------------------
   UNIRAS (UK Govt CERT) Briefing Notice - 130/04 dated 19.03.04  Time: 14:10  
  UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre)
- ---------------------------------------------------------------------------------- 
  UNIRAS material is also available from its website at www.uniras.gov.uk and
         Information about NISCC is available from www.niscc.gov.uk
- ----------------------------------------------------------------------------------

Title
=====

Security Issue Involving the Solaris sadmind(1M) Daemon (Revised)

Detail
====== 

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.



       ESB-2004.0222 -- Sun(sm) Alert Notification - SunAlert: 56740
     Security Issue Involving the Solaris sadmind(1M) Daemon (Revised)
                               19 March 2004

Product:                sadmind
Publisher:              Sun Microsystems
Operating System:       Solaris 9
                        Solaris 8 and Trusted Solaris 8
                        Solaris 7 and Trusted Solaris 7
Platform:               SPARC
                        IA-32
Impact:                 Root Compromise
Access Required:        Remote

Ref:                    ESB-2003.0646

- - --------------------------BEGIN INCLUDED TEXT--------------------

   DOCUMENT ID: 56740
   SYNOPSIS: Security Issue Involving the Solaris sadmind(1M) Daemon
   DETAIL DESCRIPTION:
   
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, 17-Mar-2004
     * Date Closed: 15-Sep-2003
     * Date Modified: 17-Mar-2004
       
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.
   
   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 without patch 116456-01
     * Trusted Solaris 7
     * Solaris 8 without patch 116455-01
     * Trusted Solaris 8
     * Solaris 9
       
   x86 Platform
     * Solaris 7 without patch 116457-02
     * Trusted Solaris 7
     * Solaris 8 without patch 116442-01
     * 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:
   
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

   This issue is addressed in the following releases:
   
   SPARC Platform
     * Solaris 7 with patch 116456-01 or later
     * Solaris 8 with patch 116455-01 or later
       
   x86 Platform
     * Solaris 7 with patch 116457-02 or later
     * Solaris 8 with patch 116442-01 or later
       
   Note: Additional patches will be forthcoming.
   
Change History

   17-Mar-2004:
     * 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-2003 Sun Microsystems, Inc., 4150 Network Circle, Santa
   Clara, CA 95054 U.S.A. All rights reserved.



- ----------------------------------------------------------------------------------

For additional information or assistance, please contact the HELP Desk by 
telephone or Not Protectively Marked information may be sent via 
EMail to: uniras@xxxxxxxxxxxx

Office Hours:
Mon - Fri: 08:30 - 17:00 Hrs
Tel: +44 (0) 20 7821 1330 Ext 4511
Fax: +44 (0) 20 7821 1686

Outside of Office Hours:
On Call Duty Officer:
Tel: +44 (0) 20 7821 1330 and follow the prompts

- ----------------------------------------------------------------------------------
UNIRAS wishes to acknowledge the contributions of Sun for the information 
contained in this Briefing. 
- ----------------------------------------------------------------------------------
This Briefing contains the information released by the original author. Some 
of the information may have changed since it was released. If the vulnerability 
affects you, it may be prudent to retrieve the advisory from the canonical site 
to ensure that you receive the most current information concerning that problem.

Reference to any specific commercial product, process, or service by trade 
name, trademark manufacturer, or otherwise, does not constitute or imply 
its endorsement, recommendation, or favouring by UNIRAS or NISCC.  The views 
and opinions of authors expressed within this notice shall not be used for 
advertising or product endorsement purposes.

Neither UNIRAS or NISCC shall also accept responsibility for any errors 
or omissions contained within this briefing notice. In particular, they shall 
not be liable for any loss or damage whatsoever, arising from or in connection 
with the usage of information contained within this notice.

UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST) 
and has contacts with other international Incident Response Teams (IRTs) in 
order to foster cooperation and coordination in incident prevention, to prompt 
rapid reaction to incidents, and to promote information sharing amongst its 
members and the community at large. 
- ----------------------------------------------------------------------------------
<End of UNIRAS Briefing>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQCVAwUBQFr/1Ypao72zK539AQF+qAP+NBQ+ZMmeEOVeG11jACpO+tGPswcC70wD
ocvz/B2ynAt3ogZONVs/Nkyfof3sE28bCQuOuvAyiqJ7TXLEKq2knp+vT/maxNX5
u6f8nvJGVYLLz7dUw/f4bexSsH5U0S/eHlz5aAhX6YYMhq89/AhS19Mpf293Rj0h
w6nS8c0gsBs=
=AZoC
-----END PGP SIGNATURE-----