By yakshaving on Feb 12, 2007
So at this point you have probably heard about the "0-day" telnet exploit which appears to be a problem with user authentication with in.telnetd. I have seen one proposed work around for the problem that I think may cause some heartburn if implemented.
In Another Good Reason to Stop Using Telnet Donald Smith reports a work around that appears to work. However in simple testing this appears to break normal applications of telnet.
e.g. if you ARE USING PASSWORD BASED USER AUTHENTICATION you will no longer be able to login
The mitigation of the vulnetability which allows logins as any user including root to login without a password.
inetdadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user"
I don't have a kerberos enabled environment to test with so I don't know if ticket based authentication would still work in this configuration.
My general thought process would be:
If you are still using telnet, hopefully it is because you absolutely need to use it.
e.g. hard coded legacy application that uses telnet
If you need to use telnet, enable tcp_wrappers and allow only telnet from your trusted and required hosts.
inetdadm -m svc:/network/telnet:default tcp_wrappers=TRUE
UPDATE 1 (02/13 9:48):
Interim Security Relief (ISRs) Patches are available in the Sun Alert document. The README does not seem to indicate that a reboot is required. If you need telnet it would seem appropriate to install these patches ASAP. (No really read the README, installing an IDR limits your ability to re-patch the affected areas without first removing the IDR)
Sun Alert ID: 102802 Security Vulnerability in the in.telnetd(1M) Daemon May Allow Unauthorized Remote Users to Gain Access to a Solaris Host
US-CERT VU#881872 Sun Solaris telnet authentication bypass vulnerability