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:

• http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2007-001-telnetd.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

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

References

110060-21
116462-06
110061-21
119796-04




Attachments

This solution has no attachment