|
Brought to you by:
Suppliers of:
|
|
|
| |
| Most of the current telnet daemons in use today suffer from a buffer overflow in the telnet option handling. Under certain circumstances, it may be possible to exploit it to gain root privileges. |
| |
Credit:
The information has been provided by scut (a.k.a. Sebastian).
|
| |
Vulnerable systems:
BSDI 4.x default (Exploitable)
FreeBSD [2345].x default (Exploitable)
IRIX 6.5 (Not exploitable)
Linux netkit-telnetd prior to 0.14 (Unknown)
NetBSD 1.x default (Exploitable)
OpenBSD 2.x (Unknown)
Solaris 2.x sparc (Unknown)
Immune systems:
Linux netkit-telnetd 0.14 and above
OpenBSD current
Impact:
By 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 privileges 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 that 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 that is able to write outside of the buffer will find it 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.
Solution:
The vendors have been notified of the problem at the same time as the rest of public, vendor patches for your telnet daemon that fix the bug will show up soon.
Sometimes a fix might not be trivial and require many 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.
|
|
|
|
|
