Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Merry Christmas from the FreeBSD Security Team

lists.freebsd.org

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Merry Christmas from the FreeBSD Security Team

#11

Post by SomeOtherGuy »

joshAg wrote: post #8
SomeOtherGuy wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Merry Christmas from the FreeBSD Security Team

#13

Post by vog »

jws wrote: post #2

A buffer overflow in telnetd that allows arbitrary execution as root from remote TCP connections. It doesn't get much worse than that. At least telnetd is disabled by default so most installs won't be vulnerable.

> 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?

Re: Merry Christmas from the FreeBSD Security Team

#14

Post by forgotusername »

SomeOtherGuy wrote: post #11
joshAg wrote: post #8

Earlier quoted context omitted.

same reason there are still Cobol jobs. Users, for various reasons (ranging from dubious to valid), refuse to update to a more modern solution.

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?

Re: Merry Christmas from the FreeBSD Security Team

#15

Post by jws »

vog wrote: post #13
jws wrote: post #2

A buffer overflow in telnetd that allows arbitrary execution as root from remote TCP connections. It doesn't get much worse than that. At least telnetd is disabled by default so most installs won't be vulnerable.

> 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 "Si…

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.)

Re: Merry Christmas from the FreeBSD Security Team

#16

Post by jws »

vog wrote: post #13
jws wrote: post #2

A buffer overflow in telnetd that allows arbitrary execution as root from remote TCP connections. It doesn't get much worse than that. At least telnetd is disabled by default so most installs won't be vulnerable.

> 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 "Si…

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.)

Re: Merry Christmas from the FreeBSD Security Team

#17

Post by matwood »

vog wrote: post #13
jws wrote: post #2

A buffer overflow in telnetd that allows arbitrary execution as root from remote TCP connections. It doesn't get much worse than that. At least telnetd is disabled by default so most installs won't be vulnerable.

> 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 "Si…

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.

Re: Merry Christmas from the FreeBSD Security Team

#18

Post by cperciva »

blumentopf wrote: post #7

Gee, that BIND vulnerability was made public mid-November and they're integrating that into FreeBSD on Dec 23 ?!

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.

Re: Merry Christmas from the FreeBSD Security Team

#19

Post by cperciva »

corbet wrote: post #3

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'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.

Post reply on HN