A hole in telnetd

An unexpected FreeBSD security team "holiday message" had an underlying cause that was, perhaps, even more surprising: a long-standing remote code execution flaw in telnetd. As the message notes, FreeBSD tries hard to avoid releasing security updates at inconvenient times, and the end of the year is pretty inconvenient for most. But, attacks were being seen in the wild and, since telnetd is typically run as root, the consequences were severe.

Some, perhaps many, readers can be forgiven for wondering what all the fuss is about, as it has been well over a decade since telnet was being actively discouraged for use on Linux (and other operating systems). It is still present in many distribution repositories, however, which led to a pile of Linux updates in addition to the FreeBSD update. It turns out that telnetd is actually being used much more than one might think, especially on embedded devices.

The reason that telnet has long been deprecated—at least over unencrypted networks—is that it is a cleartext protocol. Logging into a remote system using telnet means that your username and password were being sent in the clear, such that any man-in-the-middle could sniff your credentials. But, it turns out that the telnet protocol does have an encrypted mode (though it's not considered cryptographically strong), and it is that mode that is being exploited by the recent attacks.

The bug itself is a fairly mundane buffer overflow that is triggered when an overlong encryption key is sent to the server. That key is sent before any authentication has occurred, which allows random attackers to target any vulnerable telnetd server. Even readers without much knowledge of C (or buffer overflows) will likely understand the basics of the patch that fixes the problem. There is also a fairly comprehensive exploit available for study. It can target multiple Linux and BSD installations, and contains shell code (i.e. code that will create a root shell when executed by telnetd because of the exploit) for i386 and SPARC architectures.

While the bug itself has been around for quite some time, it is interesting—nearly amusing—to see that sites still have telnetd servers running. The updates imply that these hosts are both accessible by untrusted users (or no update would be needed) and are regularly accessed via telnet. There are few, if any, Linux distributions that enable telnetd by default, so administrators or device makers are knowingly enabling it. While sshd most certainly has had its share of bugs, and will likely have more down the road, one would guess that security researchers pay a lot more attention to sshd than they do to telnetd. Not so for attackers evidently.

Part of the reason that telnetd may still be hanging around is that Windows doesn't ship an SSH client, but does ship telnet. That may encourage device makers to enable telnet so that Windows users can access the device without installing any software. In addition, there were several reports that Cisco and Juniper routers are often accessed via telnet in the comment thread on our posting of the FreeBSD message. Given that those devices often sit in strategic internet locations, and may well be running a telnetd descended from the vulnerable code, it could lead to some fairly serious consequences. One hopes that Cisco, Juniper, and others are paying attention.