Merry Christmas from the FreeBSD Security Team(lists.freebsd.org)
lists.freebsd.org
Merry Christmas from the FreeBSD Security Team
http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/000165.html
4 comments
> 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?
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.)
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.
Could you add something to the title explaining what this is about? maybe (Telnet remote root vulnerability) or something like that
It seemed to me that "Merry Christmas" was a good way of covering "look at the 5 presents we just sent you".
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...
I'm amazed that telnet still lives after all these years.
I wonder if anybody has audited telnetd implementations on other systems for the same problem?
I wonder if anybody has audited telnetd implementations on other systems for the same problem?
I'm amazed that telnet still lives after all these years.
I'm going to be asking if anyone objects to me axing it from FreeBSD soon.
I wonder if anybody has audited telnetd implementations on other systems for the same problem?
All BSD-derived telnetd implementations are likely to have this bug.
I'm going to be asking if anyone objects to me axing it from FreeBSD soon.
I wonder if anybody has audited telnetd implementations on other systems for the same problem?
All BSD-derived telnetd implementations are likely to have this bug.
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.
Yeah, lots of switches use telnet too. Most of those are (hopefully!) on a backhaul private vlan though.
I'm pretty sure openbsd is fine, since they removed telnetd from the OS years ago. The big question is, why do other systems still have a telnetd?
same reason there are still Cobol jobs. Users, for various reasons (ranging from dubious to valid), refuse to update to a more modern solution.
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?
This is the piece that allows you to telnet /into/ a new shiny FreeBSD box, for which there are no legitimate uses in 2011.
If they take this bit out, you can still telnet out to your embedded hardware, L2 switches, and the like.
If they take this bit out, you can still telnet out to your embedded hardware, L2 switches, and the like.
Gee, that BIND vulnerability was made public mid-November and they're integrating that into FreeBSD on Dec 23 ?!
Not quite...
Corrected:
Corrected:
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.