CETS Fling and Alliance Policy

There are currently two CGI web servers available, Fling and Alliance. Fling and Alliance are
identical machines with the same configurations. Alliance is for production sites and services run by faculty and staff. Everyone
should use Fling for experiments and development.

Fling and Alliance are not restricted to SEASnet
or PennNet. Fling and Alliance are accessible
from anywhere on the Internet.

The SEAS policy and privacy statement apply to Fling and Alliance except for the following provisions:

Servers

Servers are prohibited on www.seas in general, but you may
test, run, and demonstrate server programs on Fling/Alliance.
You have been given access to Fling/Alliance for
a specific project, and only servers and CGI scripts relating
to that project may be run on Fling/Alliance.

Monitoring

Unlike the general machines on www.seas, your use of Fling/Alliance is restricted to testing and demonstrating server programs and
CGI scripts for a specific project. CETS reserves the right to
routinely monitor all processes running on Fling, and
all network traffic to and from Fling/Alliance.

Stability and reliability

Since Fling is intended for testing and
demonstration of experimental services, we expect it to be unstable.
CETS staff will kill any process that we suspect might be interfering
with system security or performance, and may reboot the system
without warning.

To avoid lost work, we recommend that you edit, compile, read
mail, and do all of your work on the general Eniac machines,
and only use Fling to test and debug your server programs.
Use Alliance for production sites and services run by faculty
and staff.

Writing Secure Server Programs

Even with the restricted access to Fling and Alliance,
you need to avoid security holes in your server programs. The two
most common problems are trusting client input and buffer overflows.

Trusting client input

Here's an example of trusting client input. Let's say that the client
enters an email address and the server sends a message to that address
using

system("/usr/ucb/mail -s howdy $ADDRESS");

and the client enters the following "address"

chip && cd && rm -rf .

Then the command becomes

system("/usr/ucb/mail -s howdy chip && cd && rm -rf .");

The server was trusting the client to enter a valid email address
and nothing else, and the client took advantage of that trust.

The solution is to keep track of all variables that contain input
from the client, and not to use those variables in any string that
will be interpreted (eg, system or popen, or back-tics
in perl or shells). If you must interpret untrusted strings,
first check that they contain what they should. For instance, you
could check that $ADDRESS matches the regular expression

[0-9a-zA-Z-_.]*(@[0-9a-zA-Z-_.]*)?

Using taintperl will help you keep track of variables that
contain untrusted information (tainted variables). If you are working
in perl, you should use taintperl for server programs. However, it
is still possible to write insecure programs in taintperl. To make
use of perl's taint-checking functionality use #!/usr/bin/perl
-T as your perl interpreter.

Buffer overflows

The buffer overflow problem is a more low level problem. If you are
reading input from the client into a fixed length buffer, and the
client sends you string longer than the buffer length, then the client
is now writing whatever it wants into your memory. This problem can
be exploited to execute arbitrary code on the server machine.

The solution is to prevent buffer overflows. Perl does not have
fixed length buffers, so using Perl avoids this problem entirely.
Other languages have ways to limit the length of the input to the
size of the buffer.