===================================================================== CERT-Renater Note d'Information No. 2007/VULN182 _____________________________________________________________________ DATE : 05/04/2007 HARDWARE PLATFORM(S) : / OPERATING SYSTEM(S) : Solaris running Sun Enterprise Authentication Mechanism. ====================================================================== Sun(sm) Alert Notification * Sun Alert ID: 102867 * Synopsis: Security Vulnerability in the SEAM Kerberized telnetd(1M) Daemon May Allow Unauthorized Remote Users to Gain Access to a Solaris Host * Category: Security * Product: Sun Enterprise Authentication Mechanism 1.0 * BugIDs: 6529370 * Avoidance: Workaround * State: Workaround * Date Released: 03-Apr-2007 * Date Closed: * Date Modified: 1. Impact A security vulnerability in the SEAM Kerberized telnetd(1M) daemon may allow a local or remote unprivileged user who is able to connect to a host using the telnet(1) service to gain unauthorized access to that host by connecting as any user on the system, allowing them to execute arbitrary commands with the privileges of that user. This includes the root user (uid 0). This issue is described in the following documents: * http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2007-001-teln etd.txt * CERT VU#220816 at: http://www.kb.cert.org/vuls/id/220816 * CVE-2007-0956 at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0956 2. Contributing Factors This issue can occur in the following releases: SPARC Platform * SEAM 1.0.1 (for Solaris 8) * SEAM 1.0.2 (for Solaris 9) x86 Platform * SEAM 1.0.1 (for Solaris 8) * SEAM 1.0.2 (for Solaris 9) Note 1: Solaris Enterprise Authentication Mechanism (SEAM) is an unbundled product available for Solaris 8 and 9. For more information on SEAM, please see the SEAM(5) man page. Note 2: There is no unbundled SEAM product for Solaris 10 and the Kerberized in.telnetd(1M) daemon which is shipped with Solaris 10 is not impacted by this issue, meaning that Solaris 10 systems are not affected by this issue. Note 3: To determine if the SEAM unbundled product is installed on a host, a command such as the following can be used: $ pkginfo SUNWkr5sv system SUNWkr5sv Kerberized Network Services Note 4: This issue only affects hosts which are configured to run the SEAM Kerberized telnetd(1M) daemon. To determine if a host is configured in this way, the inetd.conf(4) file can be examined using a command such as the following: $ grep usr/krb5/lib/telnetd /etc/inetd.conf telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd Note 5: If affected hosts are configured to only allow Kerberos authenticated logins via the telnet(1) protocol, then only users who are able to correctly authenticate with the server would be able to take advantage of this issue. The default telnetd(1M) authentication configuration is stored in the file "/etc/default/telnetd", e.g: $ grep AUTH= /etc/default/telnetd AUTH=user If this file does not exist, or if the AUTH value is "none" (the default setting) any user may exploit this issue without authenticating. 3. Symptoms Depending on the manner in which this issue has been exploited, the output from commands such as last(1) (which display information about login and logout activity), may show unexpected logins to the system. Using the "-a" flag with the last(1) command will show the hostname associated with these logins. 4. Relief/Workaround To workaround this issue, the Kerberized telnetd(1M) service can be disabled by removing (or commenting out) the appropriate line in the inetd.conf(4) file and then forcing inetd to reload this configuration file. For example: 1. Comment out the telnet service: $ grep usr/krb5/lib/telnetd /etc/inetd.conf #telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd 2. Send the HUP signal to the inetd process (which requires root access): # pkill -HUP inetd 3. Confirm that it is no longer possible to connect to the host with telnet: $ telnet localhost Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused The non-Kerberized in.telnetd(1M) daemon that is shipped with Solaris 8 and 9 is not impacted by this issue. Sites wishing to retain access to the telnet service may wish to enable this daemon as a replacement. However, this will not provide the security features (such as encryption and authentication) that are part of the Kerberos protocol, and is therefore less secure. The inetd.conf(4) documentation describes how to enable a service. Until patches can be applied, you may wish to block access to the telnet service from untrusted networks such as the Internet. 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. 5. Resolution A final resolution is pending completion. 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 ====================================================================== ========================================================= Les serveurs de référence du CERT-Renater http://www.urec.fr/securite http://www.cru.fr/securite http://www.renater.fr ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 151 bd de l'Hopital | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + =========================================================