COMMAND
telnetd
SYSTEMS AFFECTED
Multiple vendor Telnet Daemon
PROBLEM
scut found following (TESO Security Advisory). Within most of
the current telnet daemons in use today there exist a buffer
overflow in the telnet option handling. Under certain
circumstances it may be possible to exploit it to gain root
priviledges remotely.
Systems affected:
System | vulnerable | exploitable *
----------------------------------------+--------------+------------------
AIX | yes |
BSDI 4.x default | yes | yes
FreeBSD [2345].x default | yes | yes
IRIX 6.5 | yes | no
Linux netkit-telnetd < 0.14 | yes | ?
Linux netkit-telnetd >= 0.14 | no |
NetBSD 1.x default | yes | yes
OpenBSD 2.x | yes | ?
OpenBSD current | no |
Solaris 2.x sparc | yes | ?
<almost any other vendor's telnetd> | yes | ?
----------------------------------------+--------------+------------------
* = From our analysis and conclusions, which may not be correct
or we may have overseen things. Do not rely on this.
Through sending a specially formed option string to the remote
telnet daemon a remote attacker might be able to overwrite
sensitive information on the static memory pages. If done
properly this may result in arbitrary code getting executed on
the remote machine under the priviledges the telnet daemon runs
on, usually root.
Within every BSD derived telnet daemon under UNIX the telnet
options are processed by the 'telrcv' function. This function
parses the options according to the telnet protocol and its
internal state. During this parsing the results which should be
send back to the client are stored within the 'netobuf' buffer.
This is done without any bounds checking, since it is assumed
that the reply data is smaller than the buffer size (which is
BUFSIZ bytes, usually).
However, using a combination of options, especially the 'AYT' Are
You There option, it is possible to append data to the buffer,
usually nine bytes long. To trigger this response, two bytes in
the input buffer are necessary. Since this input buffer is BUFSIZ
bytes long, you can exceed the output buffer by as much as
(BUFSIZ / 2) * 9) - BUFSIZ bytes. For the common case that BUFSIZ
is defined to be 1024, this results in a buffer overflow by up to
3584 bytes. On systems where BUFSIZ is defined to be 4096, this
is an even greater value (14336).
Due to the limited set of characters an attacker is able to write
outside of the buffer it is difficult - if not impossible on some
systems - to exploit this buffer overflow. Another hurdle for a
possible attacker may be the lack of interesting information to
modify after the buffer.
This buffer overflow should be considered serious nevertheless,
since experience has shown that even complicated vulnerabilities
can be exploited by skilled attackers, BIND TSIG and SSH deattack
come to mind.
TESO have constructed a working exploit for any version of BSDI,
NetBSD and FreeBSD. Exploitation on Solaris sparc may be
possible but if it is, it is very difficult involving lots of
arcane tricks. OpenBSD is not as easily exploitable as the other
BSD's, because they do compile with other options by default,
changing memory layout.
On TESO request (Sebastian) this exploit has been removed from
this advisory.
Here is the scanner:
/*
* Telnetd AYT overflow scanner, by Security Point(R)
* Bug found by scut of TESO Security
*
* Date: 25/07/01
* Author: Security Point(R)
* WWW: http://www.secpoint.com
* Email: info@secpoint.com
*
* This program checks for the AYT overflow realted to the
* newly discovered telnetd vulnerabilities.
*
* Tested agianst:
* Vulnerable:
* netkit-telnet-0.10
* FreeBSD 4.2
* Not vulnerable:
* netkit-telnet-0.17
*
* Please keep us updated whith the os's that you check, and
* report back to us on info@secpoint.com, weather the system
* is vulnerable or not. So we can construct a full list
* of vulnerable systems.
*
*
* This source code is for educational purpose ONLY,
* Security Point(R) will not be responsible for any damages
* whatsoever that have a connection with this code. There are
* no warranties with regard to this information.
*
* Are your networks under attack at this moment?
*
* With Security Point(R) Scanner you can find and repair the
* Vulnerabilities before the bad guys get in.
*
* Please see http://www.secpoint.com/solutions.php
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <netdb.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>
#include <sys/socket.h>
struct in_addr addr;
struct sockaddr_in address;
struct hostent *host;
int sock;
char sendbuffer[5120*2];
char buffer[5120*2];
int i;
int timeout;
void handle_alarm(int signum) {
alarm(0);
timeout=1;
}
int main (int argc, char *argv[]) {
printf("Telnetd AYT overflow scanner, by Security Point(R)\n");
if (argc!=2) {
printf("Usage: %s <host>\n", argv[0]);
exit(EXIT_FAILURE);
}
printf("Host: %s\n", argv[1]);
if ((host=gethostbyname(argv[1])) == NULL) {
perror("gethostbyname");
exit(0);
exit(EXIT_FAILURE);
}
if (( sock = socket(AF_INET, SOCK_STREAM,0)) < 0) {
perror("socket");
exit(EXIT_FAILURE);
}
bcopy(host->h_addr, (char *)&address.sin_addr, host->h_length);
address.sin_family=AF_INET;
address.sin_port = htons(23); // telnet
if (connect(sock, (struct sockaddr*)&address, sizeof(address)) < 0) {
perror("connect");
exit(EXIT_FAILURE);
}
printf("Connected to remote host...\n",argv[1]);
printf("Sending telnet options... stand by...\n");
signal(SIGALRM,handle_alarm);
bzero(sendbuffer,sizeof(sendbuffer));
for (i=0;i!=(sizeof(sendbuffer)/2);i++) {
sprintf(sendbuffer,"%s%c%c",sendbuffer,255,246); // 0xff 0xf6 - IAC AYT
}
alarm(60);
read(sock, buffer, sizeof(buffer));
alarm(0);
write(sock, sendbuffer, strlen(sendbuffer));
bzero(buffer,sizeof(buffer));
alarm(60);
if (read(sock, buffer, sizeof(buffer)) <=0) {
printf("Telnetd on %s vulnerable\n",argv[1]);
exit(EXIT_SUCCESS);
}
alarm(0);
printf("Telnetd on %s not vulnerable\n",argv[1]);
exit(EXIT_SUCCESS);
}
SOLUTION
The vendors have been notified of the problem at the same time as
the general public, vendor patches for your telnet daemon that
fix the bug will show up soon.
Sometimes a fix might not be trivial and require a lot of changes
to the source code, due to the insecure nature the 'nfrontp'
pointer is handled. The best long term solution is to disable
the telnet daemon at all, since there are good and free
replacements.
All current versions of BSD/OS are vulnerable. Patches are
available via our web site at
http://www.bsdi.com/services/support/patches
ftp://ftp.bsdi.com/bsdi/support/patches
All released versions of FreeBSD are vulnerable to this problem,
which was fixed in FreeBSD 4.3-STABLE and FreeBSD 3.5.1-STABLE on
July 23, 2001. An advisory has been released, along with a patch
to correct the vulnerability and a binary upgrade package
suitable for use on FreeBSD 4.3-RELEASE systems. For more
information, see the advisory at the following location:
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-01:49.telnetd.asc
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html
For IBM AIX the temporary fixes can be downloaded via ftp from:
ftp://aix.software.ibm.com/aix/efixes/security/telnetd_efix.tar.Z
For SCO OpenServer:
ftp://ftp.sco.com/pub/security/openserver/sr849876/
For Red Hat:
ftp://updates.redhat.com/5.2/en/os/SRPMS/telnet-0.17.5x-18.src.rpm
ftp://updates.redhat.com/5.2/en/os/alpha/telnet-0.17.5x-18.alpha.rpm
ftp://updates.redhat.com/5.2/en/os/i386/telnet-0.17.5x-18.i386.rpm
ftp://updates.redhat.com/5.2/en/os/sparc/telnet-0.17.5x-18.sparc.rpm
ftp://updates.redhat.com/6.2/en/os/SRPMS/telnet-0.17.6x-18.src.rpm
ftp://updates.redhat.com/6.2/en/os/alpha/telnet-0.17.6x-18.alpha.rpm
ftp://updates.redhat.com/6.2/en/os/alpha/telnet-server-0.17.6x-18.alpha.rpm
ftp://updates.redhat.com/6.2/en/os/i386/telnet-0.17.6x-18.i386.rpm
ftp://updates.redhat.com/6.2/en/os/i386/telnet-server-0.17.6x-18.i386.rpm
ftp://updates.redhat.com/6.2/en/os/sparc/telnet-0.17.6x-18.sparc.rpm
ftp://updates.redhat.com/6.2/en/os/sparc/telnet-server-0.17.6x-18.sparc.rpm
ftp://updates.redhat.com/7.0/en/os/SRPMS/telnet-0.17-18.src.rpm
ftp://updates.redhat.com/7.0/en/os/alpha/telnet-0.17-18.alpha.rpm
ftp://updates.redhat.com/7.0/en/os/alpha/telnet-server-0.17-18.alpha.rpm
ftp://updates.redhat.com/7.0/en/os/i386/telnet-0.17-18.i386.rpm
ftp://updates.redhat.com/7.0/en/os/i386/telnet-server-0.17-18.i386.rpm
ftp://updates.redhat.com/7.1/en/os/SRPMS/telnet-0.17-18.src.rpm
ftp://updates.redhat.com/7.1/en/os/alpha/telnet-0.17-18.alpha.rpm
ftp://updates.redhat.com/7.1/en/os/alpha/telnet-server-0.17-18.alpha.rpm
ftp://updates.redhat.com/7.1/en/os/i386/telnet-0.17-18.i386.rpm
ftp://updates.redhat.com/7.1/en/os/i386/telnet-server-0.17-18.i386.rpm
ftp://updates.redhat.com/7.1/en/os/ia64/telnet-0.17-18.ia64.rpm
ftp://updates.redhat.com/7.1/en/os/ia64/telnet-server-0.17-18.ia64.rpm
For Conectiva Linux:
ftp://atualizacoes.conectiva.com.br/4.0/SRPMS/telnet-0.17-1U40_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.0/i386/telnet-0.17-1U40_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.0es/SRPMS/telnet-0.17-1U40_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.0es/i386/telnet-0.17-1U40_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/telnet-0.17-1U41_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.1/i386/telnet-0.17-1U41_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/telnet-0.17-1U42_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/4.2/i386/telnet-0.17-1U42_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/telnet-0.17-1U50_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/5.0/i386/telnet-0.17-1U50_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.0/i386/telnet-server-0.17-1U50_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/telnet-0.17-1U51_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/5.1/i386/telnet-server-0.17-1U51_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/5.1/i386/telnet-0.17-1U51_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/telnet-0.17-2U60_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/telnet-server-0.17-2U60_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/6.0/RPMS/telnet-0.17-2U60_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/SRPMS/telnet-0.17-2U70_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/telnet-0.17-2U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/7.0/RPMS/telnet-server-0.17-2U70_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/SRPMS/telnet-0.17-1U50_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/telnet-0.17-1U50_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/telnet-server-0.17-1U50_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/SRPMS/telnet-0.17-1U50_1cl.src.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/telnet-0.17-1U50_1cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/telnet-server-0.17-1U50_1cl.i386.rpm
For SGI:
OS Version Patch #
---------- -------
IRIX 6.5 4354
IRIX 6.5.1 4354
IRIX 6.5.2 4354
IRIX 6.5.3 4354
IRIX 6.5.4 4354
IRIX 6.5.5 4354
IRIX 6.5.6 4354
IRIX 6.5.7 4354
IRIX 6.5.8 4354
IRIX 6.5.9 4354
IRIX 6.5.10 4354
IRIX 6.5.11 4354
IRIX 6.5.12 4354
IRIX 6.5.13 4354
For Kerberos the recommended approach is to apply the appropriate
patches and to rebuild your telnetd. Patches for the krb5-1.2.2
release may be found at:
http://web.mit.edu/kerberos/www/advisories/telnetd_122_patch.txt