Note: This is an archival copy of Security Sun Alert 228520 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1017423.1.
Sun Enterprise Authentication Mechanism 1.0
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:
This issue can occur in the following releases:
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.
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 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.
This issue is addressed in the following releases:
This solution has no attachment