More info here -- http://www.cert.org/advisories/CA-2001-21.html Raan Young TESO Security Advisory 07/18/2001 Multiple vendor Telnet Daemon vulnerability Summary =================== Within most of the current telnet daemons in use today there exists a buffer overflow in the telnet option handling. Under certain circumstances it may be possible to exploit it to gain root priviledges remotely. A valid user account and password is not required to exploit this vulnerability, only the ability to connect to a telnetd server. This vulnerability is known to be exploitable, and is being actively exploited in the wild. Systems Affected =================== System | vulnerable | exploitable* ----------------------------------------+--------------+------------------ 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 overlooked things. Do not rely on this. Impact =================== 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. Explanation =================== 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 sent 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. Nevertheless, this buffer overflow should be considered serious, since experience has shown that even complicated vulnerabilities can be exploited by skilled attackers -- BIND, TSIG and SSH deattack come to mind. We 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. Workarounds =================== 1) Disable the telnet service, which is usually run out of inetd. 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.
This archive was generated by hypermail 2b30 : Sun May 26 2002 - 11:24:03 PDT