Note: This is an archival copy of Security Sun Alert 200150 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000108.1.
Solaris 9 Operating System
Solaris 2.6 Operating System
Solaris 7 Operating System
Solaris 8 Operating System
Date of Resolved Release
Unprivileged local or remote users may be able to cause the in.telnetd(1M) daemon process to enter an infinite loop resulting in large amounts of CPU time being used.
With multiple "in.telnetd" processes in this looping state the system may become unresponsive as a whole.
This issue can occur in the following releases:
Solaris 2.5.1 will not be evaluated regarding the potential impact of the issue described in this Sun Alert document.
Tracing a looping "in.telnetd" process using the truss(1) command will show the following pattern of repeated failing "putmsg()" calls:
[...] putmsg(0, 0xEFFFF934, 0xEFFFF928, 0) Err#60 ENOSTR putmsg(0, 0xEFFFF934, 0xEFFFF928, 0) Err#60 ENOSTR putmsg(0, 0xEFFFF934, 0xEFFFF928, 0) Err#60 ENOSTR putmsg(0, 0xEFFFF934, 0xEFFFF928, 0) Err#60 ENOSTR [...]
To minimize the risk imposed by this issue, restrict incoming telnet connections to origins within trustworthy networks, e.g. by using firewalls, packet filtering software, or TCP-wrappers.
Alternatively, incoming telnet connections may be entirely disabled by commenting out the "in.telnetd" related line in the "/etc/inetd/inetd.conf" file using the hash ("#") character as shown in the following example:
#telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
For the above change to become active, the "inetd" process has to be sent a "HUP" signal by issuing the following command as root user:
# kill -HUP <pid of inetd>
(here, "<pid of inetd>" has to be replaced by the process ID of the "inetd" process).
This issue is addressed in the following releases:
This solution has no attachment