Maximum Mac OS X Security
SSH can replace a number of protocols. Included here is some information on vulnerabilities for two of the most popular protocols it is used to replace: telnet and rlogin.
telnet
telnet's single largest vulnerability is in its specification, but as a demonstration of the additional insecurity that can be found, even in an application that never tried to be secure in the first place, we've included a listing of some recent telnet vulnerabilities, as well as NCSA Telnet vulnerabilities, since 1991. These telnet vulnerabilities turn out to be typical Unix application vulnerabilities, and problems of this type are common in most Unix network applications: vulnerabilities that can allow arbitrary execution of code as the process owner and a vulnerability that can lead to denial of service.
Although these vulnerabilities are serious, the most serious vulnerability that telnet has is its inherent cleartext nature. The telnet protocol transmits everything, including usernames and passwords, in cleartext. The best solution to this vulnerability is to not enable telnet, and not use it as a client. If you are curious about seeing what telnet traffic looks like, install Etherpeek, IPNetMonitor, or Snort, or use the built-in tcpdump program, or any other similar package on a machine, do a bit of telnetting around, and see how much you can see with the sniffers. You can find these programs at http://www.wildpackets.com/products/etherpeek_mac, http://www.sustworks.com/site/prod_ipm_download.html, http:// sourceforge .net/projects/snort/, and under man tcpdump in the man pages. The telnet protocol RFC is available at http://www.ietf.org/rfc/rfc0854.txt.
telnet vulnerabilities include the following:
-
Buffer Overflow in BSD Derived Versions of telnetd (CVE-2001-0554, CA-2001-21)
A buffer overflow in BSD derived versions of telnetd can result in either crashing the system, or in the arbitrary execution of code with the privileges of telnetd , usually root . More information can also be found at ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-01:49.telnetd.v1.1.asc.
Mac OS X was affected by this vulnerability, but it was fixed with the release of Mac OS X 10.1.
-
Denial of Service Vulnerability (BugTraq ID 1955)
The TERMCAP telnet variable in client-server negotiations can cause telnetd to search the file system for files containing termcap entries. Because this is done before authentication, an attacker can cause many telnetd processes to be started, thereby exhausting system resources.
This was found to be a vulnerability in many versions of FreeBSD, but patches fixed the problem. However, there were no reports of the vulnerability having been exploited.
-
Environment Variable Format String Vulnerability (CVE-2000-0733, IN-2000-09, BugTraq ID 1572)
With the way telnetd sets the _RLD environment variable, an intruder can supply data to telnetd such that it can be executed with the privileges of telnetd, usually root.
The exploit was used to add accounts with root privileges; install root kits containing replacements for various commands, including telnetd; install packet sniffers; and/or install irc proxy programs.
This vulnerability was discovered in various versions of IRIX. Patches were made available to fix the problem.
-
Mac/PC NCSA Telnet Vulnerability (CVE-1999-1090, CA-1991-15)
This vulnerability does not exploit anything inherent to telnet itself. The default configuration for NCSA Telnet for the PC and Macintosh enables FTP with no password setting. This can result in an intruder gaining read/write access to a system, including its system files.
The temporary solution to this problem was either to specifically disable FTP or to enable password protection. NCSA later changed that default. In a later release, NCSA changed how the configuration for the program was set ”from having the settings in an external text file called config.tel to setting them in a graphical interface. Support for NCSA Telnet was discontinued with version 2.6, which was released in October 1994.
rlogin
Like telnet, vulnerabilities involving rlogin include typical vulnerabilities: buffer overflows from which root access can be gained .
Although such vulnerabilities are serious, the most serious vulnerability with rlogin, like telnet, is that it transmits everything, including usernames and passwords, in cleartext. As with telnet, the best solution to this vulnerability is to not enable rlogind .
NOTE
Believe it or not, rlogin was an attempt at a secure protocol. It was developed at a time when Unix machines were owned by companies, and personal Unix machines were rare. Security-conscious system administrators did not want to incur security problems on either their own machines or someone else's. They never created an account for a "bad" user . Therefore, someone connecting to a system via rlogin was assumed to be a trustworthy user coming from another Unix system. The rlogin RFC, available at http://www.ietf.org/rfc/rfc1282.txt, contains a cautionary tale on the security problems that spoofing a trusted host might incur. However, the RFC does not express any concern about rlogin's transmission of data in cleartext. Obviously, the author never envisioned a world with so many untrustable Unix hosts and users. |
Vulnerabilities involving rlogin include:
-
Buffer Overflow in System V “Derived login (CVE-2001-0797, CA-2001-34, BugTraq ID 3681)
A buffer overflow occurs in System V “derived versions of login when they handle environment variables . The vulnerability can be exploited to execute arbitrary code with the privileges of login . When login is called by applications that use it for authentication, its privileges are elevated to those of the application. For telnetd , rlogind , and sshd , if it is so configured, the privileges are that of root . As a result of the login buffer overflow, an intruder can gain root access to a system.
Vendors have made patches available to fix the problem.
-
Buffer Overflow Vulnerability (CVE-1999-0046, CA-1997-06, BugTraq ID 242)
The handling of the TERM variable in some implementations of rlogin can cause a buffer overflow, which can result in the arbitrary execution of code as root .
This vulnerability was discovered in many versions of Unix. Vendors made patches available to fix the problem.
| |
| Top |