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
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
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
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.
to post comments)