Date: Wed, 18 Jul 2001 17:10:38 -0400 From: "Joseph Gleason" <clash@tasam.com> To: <freebsd-security@FreeBSD.ORG> Subject: Fw: remote root vulnerability Message-ID: <002b01c10fce$18317aa0$0b2d2d0a@battleship>
next in thread | raw e-mail | index | archive | help
Anyone know if this is real? I received it from a source I don't have any strong reason to trust. > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > - ------ > > TESO Security Advisory > 06/10/2001 > > Multiple vendor Telnet Daemon vulnerability > > > Summary > =================== > > 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 * > ----------------------------------------+--------------+-------------- ---- > 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. > > Details about the systems can be found below. > > > 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 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. > > 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. > > > 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. > > > Acknowledgements > =================== > > The bug has been discovered by scut. > > The tests and further analysis were done by smiler, lorian, zip and scut. > > > Contact Information > =================== > > The TESO crew can be reached by mailing to teso@team-teso.net > Our web page is at http://www.team-teso.net/ > > > References > =================== > > [1] TESO > http://www.team-teso.net/ > > > Disclaimer > =================== > > This advisory does not claim to be complete or to be usable for any > purpose. Especially information on the vulnerable systems may be inaccurate > or wrong. Possibly supplied exploit code is not to be used for malicious > purposes, but for educational purposes only. > > This advisory is free for open distribution in unmodified form. > Articles that are based on information from this advisory should include > link [1]. > > > Exploit > =================== > > Not this time. Not here. > > - ------ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE7VfBscZZ+BjKdwjcRAsTcAJ9esSlkS7BGkYM1Yulaz3zINqxpmgCeM885 > 3thubMQc+6S4RpHasL0qz0Y= > =VT7y > -----END PGP SIGNATURE----- > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002b01c10fce$18317aa0$0b2d2d0a>