From: "Todd Heberlein" 
Subject: Vulnerabilities minutes, 5 Nov 1997
Date: Wed, 5 Nov 1997 17:06:54 -0600

Minutes from the Vulnerabilities meeting on 5 Nov 1997

Attendees: Matt Bishop, David O'Brien, Peter Mell, Ricardo Anguiano, Todd Heberlein, Jeff Rowe, Kim Knowles, and Steve Samorodin.



  1. remote user can cause resources to be used on the local machine;
  2. root is typically not restricted to its resource utilization (e.g., root is not limited in the number of processes it can own).
Peter presented a network-based denial of service attack. The attack opens many simultaneous sendmail connections to a given server. Each new connections forks off a new sendmail process, and eventually the memory and process table fill up. While initially launched against sendmail, the attack works against any network service which forks a new process for each new connection (e.g., telnetd). Sendmail and telnetd both are launched with user ID = root, and this appears to give them greater reign to fill up the computer resources (since root is not limited in the resources it can use). Initially the attack did not work well because the attacking software (the client) was restricted to the number of file descriptors it could have, and hence the number of connections it could keep open at any one time. Peter solved this by creating a master client which forked off slaves, each of which would open 200 connections to the target machine. The attack software would determine when a machine has been overwhelmed when it no longer receives any data on the initial connection. In other words, each new connection initially reads data from the target, and if no data is received, it assumes the target is effectively dead. Because of this behavior, the attack did not succeed against rlogind, since rlogind waits for input from the client before it sends any data back. Two solutions to this are (1) don't bother waiting for any data to come back from the server, and (2) send fake data to the rlogin client (see rlogin protocol for data format). The attack code currently runs on Linux, but Peter is in the process of porting it to Solaris.


  1. remote user can cause resources to be used on the local machine;
  2. on SunOS, the OS does not restrict resource utilization by any user (could someone please confirm this?).
Steve Samorodin presented a similar attack which is really a testing suite for web servers that his roommate is developing. The software is designed to test Quality of Service (QOS) of web servers by trying to access moderate to large size files very rapidly. For example, they might start by trying to access 10 pages per second, 15 pages/sec, etc. They tested the limits of several web servers, but when they tested the limit of the security lab's web server, the machine died (and very quickly). [NOTE: Since the Web server was on the same machine as the NIS server, this attack took down all the machines which relied on NIS. Another example of an indirect attack]. The security lab server (running on Olympus) is a SunOS box with an old Cern web server. The web server forks off a new copy for each page requests (apparently, many web servers do this to some degree), and when many requests came in rapid succession (too quickly to allow the previous requests to complete) too many copies were forked off and operating at the same time until the system died. Thus, the attack is similar to Peter's in that it creates many connection, each which creates a new process, until the memory or the process table fills up. However, this software wasn't really designed to be an "attack". The current software runs on an SGI, is written in C++, and relies heavily on foundation classes Fritz (?) already developed. Bringing the code into the isolated network will require permission from the developer, and potentially porting all of his foundation classes. An alternative may be to also modify Peter's code to perform a similar task (requesting many web pages).


FUNDAMENTAL VULNERABILITIES: Inconsistency when a symbolic link is used: the SUID program checks the ownership of the symbolic link but not the target of the symbolic link. Steve also presented an SUID attack which must be launched after you initially have a login shell. Detecting this from a network monitor can be difficult since it is trivial to hide (e.g., changing the name of the shell script), but reinforces our belief that all new vulnerabilities are old vulnerabilities dressed new code. The program sdtcm_convert is a calendar data conversion utility which comes with the Solaris Common Desktop Environment (CDE) distribution. The program is an SUID root program, but the documentation says that you can only run the conversion program on calendar files you own. [NOTE: I have not figured out exactly why this program *has* to be run with root privileges]. Unfortunately, if the supplied file name is a symbolic link, the program checks to make sure you own the symbolic link but it does not check to see if you own the actual target. The program then modifies the target file, and then changes the ownership of the target file to you! For example: Symbolic Link Target ------ ------ file 1 ---> file 2 owner(file 1) == you owner(file 2) == root sdtcm_convert checks to make sure you own file 1, then it modifies file 2, and then changes the ownership of file 2. owner(file 1) == you owner(file 2) == you Note, file 2 may be (probably will be) corrupted by this operation, but you will now own the file, so you can modify it. A typical target would be the password file. HISTORY NOTE #1: The r* commands (e.g., rsh) used to suffer from the dual of this problem. When using the .rhosts file for access control, the r* command would check to make sure the requested user name actually owned the .rhosts file. For example, an rsh command to the account "todd" would require that the .rhosts file was also owned by "todd". However, if .rhosts was a symbolic link, the r* command checked the owner of the target and *not* owner of the symbolic link. For example, if (1) user "todd" did not have a .rhosts file and (2) todd owned the file "foo" but left it world writeable, the bad guy could modify the file foo to look like a .rhosts file (e.g., put "+ +" at the beginning) and then create a symbolic link named .rhosts to it. Symbolic Link Target ------ ------ .rhosts ---> foo owner(.rhosts) == bad_guy owner(foo) == todd HISTORY NOTE #2: Tsutomu's famous "gimme" script exploited symbolic links to get rdist to change the permission (and on some systems, the ownership) of a given file. LESSON LEARNED: SUID programs and symbolic links don't mix well.