Security Vulnerability in the SEAM Kerberized telnetd(1M) Daemon May Allow Unauthorized Remote Users to Gain Access to a Solaris Host



Category :Security
Release Phase :Resolved
Product :Sun Enterprise Authentication Mechanism 1.0  
Bug Id :6529370  
Date of Workaround Release :03-APR-2007 
Date of Resolved Release :04-APR-2007 


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:


Contributing Factors

This issue can occur in the following releases:

SPARC Platform

  • SEAM 1.0.1 (for Solaris 8) without patch 110060-21
  • SEAM 1.0.2 (for Solaris 9) without patch 116462-06

x86 Platform

  • SEAM 1.0.1 (for Solaris 8) without patch 110061-21
  • SEAM 1.0.2 (for Solaris 9) without patch 119796-04

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.


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.


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.


Resolution

This issue is addressed in the following releases:

SPARC Platform

  • SEAM 1.0.1 (for Solaris 8) with patch 110060-21 or later
  • SEAM 1.0.2 (for Solaris 9) with patch 116462-06 or later

x86 Platform

  • SEAM 1.0.1 (for Solaris 8) with patch 110061-21 or later
  • SEAM 1.0.2 (for Solaris 9) with patch 119796-04 or later



Modification History


Date: 04-APR-2007
  • State: Resolved
  • Updated Contributing Factors and Resolution sections



Attachments
This solution has no attachment

 
 
Login Required

You must login and have a valid contract to access Sun's Premium content which includes:

  • Sun Alerts
  • Bugs
  • Patches
  • Solutions
  • White Papers
  • Documentation
  • Support Knowledge

Login Required

You must login and have a valid contract to access Sun's contracted features

Access Legend:

(Login to access)   Sun Contracted Content
(Login to access)   Sun Contracted Feature

Please make use of SunSolve Feedback application by selecting the floating [+] to provide feedback about this specific document.

Search

Article Details
Article ID : 228520
Article Type : Sun Alert
Last reviewed : 2007-04-05
Audience : PUBLIC
Keywords :
Provide feedback  (help)
Page Tools
»  Print This Page
»  Email This Article
»  Bookmark This Article
 
Contact About Sun News & Events Employment Site Map Privacy Terms of Use Trademarks Copyright Sun Microsystems, Inc. | SunSolve Version 7.4.0 #1