TelnetD suffers from remotely applicable system resource consumption (Patch available)
19 Nov. 2000
Summary
TelnetD is the server for the telnet remote login protocol. A vulnerability in the daemon allows remote attackers to cause system resources such as CPU and disk read bandwidth to be consumed, without requiring a valid login account on the server. This enables to perform an attack that causes increased server load and possibly denying service to legitimate users.
The telnet protocol supports passing UNIX environment variables from the client to the user login session on the server. However, some of these environment variables have special meaning to the telnetD child process itself and may be used to affect its operation.
Of particular relevance is the ability for remote users to cause an arbitrary file on the system to be searched for termcap data by passing the TERMCAP environment variable. Although any file on the local system can be read since the telnetD server runs as root, the contents of the file will not be reported in any way to the remote user unless it contains a valid termcap entry, in which case the corresponding termcap sequences will be used to format the output sent to the client. It is believed there is no risk of data disclosure through this vulnerability.
However, an attacker who forces the server to search through a large file or to read from a device can cause resources to be spent by the server, including CPU cycles and disk read bandwidth, which can increase the server load and may prevent it from servicing legitimate user requests. Since the vulnerability occurs before the login(1) utility is spawned, it does not require authentication to a valid account on the server in order to exploit.
All released versions of FreeBSD prior to the correction date including 4.0, 4.1, 4.1.1 and 3.5.1 are vulnerable to this problem, but it was fixed in the 4.1.1-STABLE branch prior to the release of FreeBSD 4.2-RELEASE.
Workaround:
1) Disable the telnet service, which is usually run out of inetd: comment out the following lines in /etc/inetd.conf, if present.
2) Impose access restrictions using TCP wrappers (/etc/hosts.allow), or a network-level packet filter such as ipfw(8) or ipf(8) on the perimeter firewall or the local machine, to limit access to the telnet service to trusted machines.
Solution:
One of the following:
1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or 3.5.1-STABLE after the respective correction dates.
2) Apply the patch below and recompile the relevant files:
