Multiple Vendor telnetd Vulnerability
BID:459
Info
Multiple Vendor telnetd Vulnerability
| Bugtraq ID: | 459 |
| Class: | Input Validation Error |
| CVE: | |
| Remote: | Yes |
| Local: | Yes |
| Published: | Oct 13 1995 12:00AM |
| Updated: | Oct 13 1995 12:00AM |
| Credit: | This vulnerability was discovered by Sam Hartman <[email protected]>, and was reported to the Bugtraq mailing list on October 31, 1995 |
| Vulnerable: |
SGI IRIX 6.3 SGI IRIX 6.2 SGI IRIX 6.1 SGI IRIX 6.0.1 XFS SGI IRIX 6.0.1 SGI IRIX 6.0 SGI IRIX 5.3 XFS SGI IRIX 5.3 SGI IRIX 5.2 SGI IRIX 5.1.1 SGI IRIX 5.1 SGI IRIX 5.0.1 SGI IRIX 5.0 Digital UNIX 4.0 Digital UNIX 3.2 G Digital OSF/1 3.2 Digital OSF/1 3.0 Digital OSF/1 2.0 Digital OSF/1 1.3 Digital OSF/1 1.2 |
| Not Vulnerable: |
Sun SunOS 4.1.4 Sun SunOS 4.1.3 Sun Solaris 2.5 Sun Solaris 2.4 IBM AIX 4.1 IBM AIX 3.2 HP HP-UX 10.20 HP HP-UX 10.0 HP HP-UX 9.0 |
Discussion
Multiple Vendor telnetd Vulnerability
A vulnerability existed in a number of in.telnetd's, that when coupled with dynamic linking introduced a very serious vulnerability. Telnet supports the passing of environment variables from a remote host. On vulnerable systems, an attacker would place a shared object containing code they are sure will be run, for instance, the crypt() function on the system. This could be via ftp, nfs, or any other method for getting a file on the system. They would then set this library to be part of their LD_PRELOAD enviroment variable. Upon telneting into the machine, when telnet exec'd /bin/login to authenticate the user, the system dynamic linker would load the library listed in the preload, which would override the normal library call. This in turn could allow a user to execute code as root.
A vulnerability existed in a number of in.telnetd's, that when coupled with dynamic linking introduced a very serious vulnerability. Telnet supports the passing of environment variables from a remote host. On vulnerable systems, an attacker would place a shared object containing code they are sure will be run, for instance, the crypt() function on the system. This could be via ftp, nfs, or any other method for getting a file on the system. They would then set this library to be part of their LD_PRELOAD enviroment variable. Upon telneting into the machine, when telnet exec'd /bin/login to authenticate the user, the system dynamic linker would load the library listed in the preload, which would override the normal library call. This in turn could allow a user to execute code as root.
Exploit / POC
Multiple Vendor telnetd Vulnerability
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Solution / Fix
Multiple Vendor telnetd Vulnerability
Solution:
Patches were made available from vendors for this problem.
SGI patches are available at http://support.sgi.com
Digital Unix patches are available at http://www.digital.com
Linux patches are available at popular Linux distribution sites such as ftp://sunsite.unc.edu
A suitable short term solution would be to replace the in.telnetd daemon with one known to not be vulnerable, or to patch a vulnerable one to not accept environment option.
Solution:
Patches were made available from vendors for this problem.
SGI patches are available at http://support.sgi.com
Digital Unix patches are available at http://www.digital.com
Linux patches are available at popular Linux distribution sites such as ftp://sunsite.unc.edu
A suitable short term solution would be to replace the in.telnetd daemon with one known to not be vulnerable, or to patch a vulnerable one to not accept environment option.
References
Multiple Vendor telnetd Vulnerability
References:
References:
- Digital Equipment Corporation (Digital Equipment Corporation)
- SGI Support (Silicon Graphics Inc.)