CETS Fling and Alliance Policy
There are currently two CGI web servers available, Fling (fling.seas.upenn.edu) and Alliance (alliance.seas.upenn.edu), identical machines with the same configurations. Alliance is for production sites and services run by faculty and staff. Fling is for experiments and development.
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.