Last updated at Tue, 25 Jul 2017 19:40:08 GMT

On December 23rd, the FreeBSD security team published an advisory stating that a previously unknown vulnerability in the Telnet daemon was being exploited in the wild and that a patch had been issued. This vulnerability was interesting for three major reasons:

  1. The code in question may be over 20 years old and affects most BSD-derived telnetd services
  2. The overflow occurs in a structure with a function pointer stored after the target buffer (Line 166)
  3. The telnet service is still prevalent enough that it was being exploited in the wild in the first place

On December 27th, Jaime Penalba Estebanez (of Painsec) released a shiny exploit for FreeBSD 8.0, 8.1, and 8.2. This exploit works extremely well due to the conditions when the vulnerability is triggered. Essentially, the location of the buffer provided by the user is static per binary (data section) and exploiting this only requires access to a copy of the same binary from the target platform and knowledge of a readable address. This is about as easy as it gets for remote memory-corruption exploits on the BSD platform.

A port of this exploit to the Metasploit Framework is in progress and we just added a scanner module that can be used to identify vulnerable instances of the telnet service. This module tries to trigger the vulnerability with an invalid pointer, causing the inetd-spawned process to exit. Since this process automatically respawns, it should be safe to scan all affected inetd-based systems. To use the scanner module, make sure your copy of the framework is updated, and launch the Metasploit Console:

$ msfconsole


msf> use auxiliary/scanner/telnet/telnet_encrypt_overflow

msf  auxiliary(telnet_encrypt_overflow) > set RHOSTS 192.168.0.0/24

msf  auxiliary(telnet_encrypt_overflow) > set THREADS 64

msf  auxiliary(telnet_encrypt_overflow) > run


[ ] 192.168.0.3:23 VULNERABLE: Linux 3.0.0-14-generic (192.168.0.3) (pts/11)...

[ ] 192.168.0.4:23 VULNERABLE: FreeBSD/amd64 (freebsd) (pts/0)\x0d\x0a\x0d\x0a...

[ ] 192.168.0.5:23 VULNERABLE: FreeBSD/i386 (freebsd) (pts/0)\x0d\x0a\x0d\x0a...

[ ] 192.168.0.6:23 NOT VULNERABLE: No reply to 64-byte Key ID: SUNTEN SunOS 5.10...

[*] Auxiliary module execution completed

Although this vulnerability was reported as a flaw in FreeBSD, it also affects other BSD variants and any telnet service based on the BSD code. This includes quite a few non-BSD systems as well, such as:

  • Older versions of Mac OS X (newer versions do not include the ENCRYPT option). 10.0-10.3 or so may be vulnerable
  • Older versions of Solaris (unconfirmed). Newer versions already enforce a 64-byte Key ID. Maybe Sun/Oracle found this and forgot to share.
  • Linux installations using inetutils telnetd (as opposed to netkit telnetd). Debian and Ubuntu still package this and some older distributions of Linux appear to ship with it by default. So far, the only "common" case appears to be RHEL3 (or at least some of its free clones).


There is a good chance that the same flaw affects (or at least, used to affect) other commercial Unix variants (BSDi, SCO, AIX, HP-UX, etc). We are still trying to identifiy which specific operating systems packaged code base on the vulnerable BSD upstream. There is also a chance that this bug will affect older embedded Unix deployments as well. So far, most of the recent embedded Linux distributions use BusyBox or NetKit for telnet, but it wouldn't be crazy for a vendor to package the inetutils version instead.

There is also a chance that this flaw affects Telnet clients; this opens the door to client-side exploitation through any method of forcing (or enticing) a user to access a particular telnet service. This is all fairly preliminary - we should have a followup blog post available soon with additional information about the scope and exploitability of this flaw.

Huge thanks to Dan Rosenberg and Brandon Perry for digging into this with me, along with all of the folks on Twitter who helped test/verify affected systems.

-HD