Note: This is an archival copy of Security Sun Alert 228520 as previously published on
Latest version of this security advisory is available from as Sun Alert 1017423.1.
Article ID : 1017423.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2007-04-04
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

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


Release Phase

Sun Enterprise Authentication Mechanism 1.0

Bug Id

Date of Workaround Release

Date of Resolved Release


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

If this file does not exist, or if the AUTH value is "none" (the default setting) any user may exploit this issue without authenticating.


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.


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
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.


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



This solution has no attachment