Re: More CGI Comments

Rob McCool (robm@ncsa.uiuc.edu)
Fri, 14 Jan 1994 11:56:18 -0600

/*
* Re: More CGI Comments by rhb@hotsand.att.com (rhb@hotsand.att.com)
* written on Jan 9, 8:04pm.
*
*
* > The other, more serious, complication is that if some binary data file
* > happens to begin with a magic number, the server would refuse to serve it
* > up (instead trying, and failing, to run it). If I'm not mistaken, most
* > common binary data formats (Sun .au, AIFF, JPEG (JFIF), MPEG, tar,
* > compressed data...) define their own series of magic numbers which are
* > unlikely to conflict, but relying on this would be dicey.
*
* This in fact points up the need to have a "smart" server. It is important
* that the server be able to identify the files it's serving not just by their
* suffix (i.e., in the mime type file) but via any available attribute
* (such as magic numbers). The information that's available differs
* among platforms and application (server) needs. I'm in agreement that
* we need a flexible method that allows the server to use it's "smarts"
* and the users' needs (e.g., the scripts I am interested in providing
* are all perl and tcl, so the #! would work for my application...).

I am really leery of doing anything with magic numbers. There is the binary
data problem (my machine's file command just identified a GIF as a C
program). Also, what is the magic number of an HTML document? A plaintext
document?

* Now a more general question that turns the previous question inside
* out. The original concern was in adding executables to directories
* that were not indicated as having executables. Well it seems that
* I can certainly have "regular" (non script) html files in executable
* directories.

Sure but when you try to retrieve them you'll get hit with a 500.

* What do I gain from having a directory "not executable"?
* Why aren't all directories cgi-bin directories?

Managability.... at the time we made a design decision to split scripts
apart from regular documents. I felt it was important to make no suffix
restrictions on script names and I didn't want to use magic numbers. It's
important to remember also that when these design decisions were made there
was no access control in the server except that provided by config files.

We made this decision because we felt it was necessary to give the server
administrator as much control as possible over script execution since it is
an inherently dangerous process.

It is extremely easy to write a careless script which gives intruders full
access to your machine. I should know, someone just executed an xterm from
my machine to theirs because of a careless misconfiguration I had. An
extremely popular CGI gateway which was released recently can be exploited
rather easily as well. Yes, fixes are on the way, yes, I am being
deliberately vague.

Now let's consider Joe Shmoe who writes a CGI script for his/her user script
directory. It won't be their fault, but they could easily seriously
compromise a system with a relatively innocent script.

I plan to add the ability to have script execution by suffix to 1.2 (since
1.1 is too close to being out the door). Access control will allow you to
turn script execution off in certain directories, as will simply not adding
the suffix maps to your mime configuration.

* I can restrict
* GET in the directories in which I really have scripts if I'm concerned
* about reading scripts...
*
* One point brought to my attention is that all directories are already
* "executable" in the NCSA server environment via the <inc var> directive
* (i.e., this takes care of my original problem of getting to the
* user variable in authentication), but it doesn't take care of things
* like forms.
*/

The server-side includes are a whole different ball of wax.

--Rob