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.


ADMINISTRATIVE NOTES

 Unresolved issue: When and where do we meet next week?

 Kim Knowles, who is now the web mistress for the security lab, will
support the Vulnerabilities web pages too.

 This Friday (7 Nov) at 2:00 Matt will hold a meeting on the
organization of attack information for the isolated network (and
possibly the SGML/HTML web pages??).  The meeting is right before
TGIF, so snacks will be available after the meeting.

 Hal Heggerstad (sp?) from Lincoln Labs will be here on the Nov.
13th, and he may be giving the department colloquium.  Hal's group
has also been collecting attack scripts and generating test suits for
intrusion detection systems, and he will probably be talking about
this effort next week.  We are currently trying to work a deal to
have them give us access to their suite of attacks.

 Paul Proctor (Chief Technical Officer) and Thomas Trebelhorn
(President) of Centrax Corporation visited Matt on Tuesday to see
about funding him and a student to do some vulnerability work for
them.  In essence, they want exactly what we are currently planning
on doing (collecting attacks, analyzing them, and cleaning them up or
rewriting them to deliver a test suite of attacks); however, they
want to focus on NT, and they want to claim "ownership" of the
attacks the student delivers for them.  In addition to funding a
student, they also want to give that student plenty of equipment on
which to do the research (e.g., several high-end NT workstations with
full development environments).

 Matt Bishop has not been able to establish a dialogue with CERT
regarding access to their "critters" (attack scripts and code).  I
have sent e-mail to Time Grance at NIST for access to any of their
attack tools, but I have yet to hear back from him.

 Matt is still waiting to get his book on SGML back from someone. 
Hopefully he will have some 


ATTACKS #1

FUNDAMENTAL VULNERABILITIES: 

 remote user can cause resources to be used on the local machine;
 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.


ATTACKS #2

FUNDAMENTAL VULNERABILITIES:

 remote user can cause resources to be used on the local machine; 
 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).


ATTACKS #3

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.

Todd