> At least telnetd is disabled by default so most installs won't be vulnerable.
I'm very surprised by this statement, and also very surprised by the following passage of the article which shows a similar spirit:
> On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time.
Rather, I would have expected something like "Since telnetd isn't used anymore anyway, we decided to remove it from our distribution." ;-)
Seriously, are there really computer systems remotely accessible via telnetd? Really? It's 2011! Even ten years ago SSH was already a standard component of every Unix system. Back then, I never considered telnetd to be an option for any remotely accessible machine. I only saw telnet-like services when people played Multi-User Dungeons (MUD), and even those systems did not need a telnetd but ran their own server processes.
The same for FTP, by the way. FTP will probably need more time to die than telnet, but alternatives like SFTP or Rsync-over-SSH have been available for years, too.
In other words: Why should we care? What kind of administrators and/or company policies are running telnetd anyway? Are those totally reckless, or am I missing something?
You probably aren't running 20 year old hardware that hasn't seen a software update since 1991. Some people are. Mostly people where the computer is incidental to the machine.
e.g. Back in the '90s the MRI scanners at my institute used VAX models that were well and truly obsolete even for the day, with tremendously obsolete versions of VMS because that was what was FDA approved and no changes could be made.
One can certainly imagine a device with a 6 figure price tag that communicates by telnet to a user supplied server. (Not our MRI scanners though, we weren't allowed to upgrade their software to support TCPIP.)
Lots of devices where the focus isn't really on the computer side of the device. Phone switches and auto-dialers come to mind as examples I have dealt with recently.
I think you risk people skipping over the message without reading the contents, because the title will make them think it's an empty 'happy holidays' message and not a vulnerability advisory...
That email went to lists which also had 5 vulnerability announcements arrive in the preceding minutes. It was an extra communiqué, not a replacement for the normal advisories.
Only thing I know of that it gets used for in my work is to talk to certain routers that don't support ssh version 2 since the software I work with doesn't support ssh version 1 anymore.
Telnet is still quite common in the embedded world. Existing tool boxes have implementations, busybox has a telnet client and daemon built-in, etc... It's easy. If the box never goes beyond a development rack it's safe. And if it's what you've been doing for 15 years there's not a lot of value in change.
Nonsense. People stick with telnet because of ignorance. That is why you remove telnetd, and force them to update. There is no difficulty in switching, and thus no valid reason not to switch.
As an example, there are entire classes of embedded platforms that support networking but barely have enough RAM even for the IP stack. Is it really sensible to add $10 to the cost of a temperature sensor just so it has enough RAM and CPU to handle SSH?
2011-11-16 23:41:13 UTC (ports tree)
2011-11-17 01:10:16 UTC (RELENG_7, 7.4-STABLE)
2011-11-17 00:36:10 UTC (RELENG_8, 8.2-STABLE)
2011-12-01 21:13:41 UTC (RELENG_9, 9.0-STABLE)
2011-12-01 21:17:59 UTC (RELENG_9_0, 9.0-RC3)
2011-12-23 15:00:37 UTC (RELENG_7_4, 7.4-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_7_3, 7.3-RELEASE-p9)
2011-12-23 15:00:37 UTC (RELENG_8_2, 8.2-RELEASE-p5)
2011-12-23 15:00:37 UTC (RELENG_8_1, 8.1-RELEASE-p7)
We sometimes delay "non-critical" advisories in order to send them out at the same time as others. In this case -- a DoS against a daemon which most FreeBSD users install from the ports tree anyway -- there wasn't much point updating the security branches earlier.
At least telnetd is disabled by default so most installs won't be vulnerable.