Re: cgis and server side includes

Ryan Shelswell (Ryan.Shelswell@nospam.uts.edu.au)
Wed, 29 May 1996 12:18:30 +1000 (EAST)

>All pages are served up using the uid nobody. Since the user nobody has
>little privileges, it cannot access directories and files that are not
>world readable (except if it was owned by nobody of course). Sounds
>pretty safe so far.
>
>This is where the fun starts. Since everything is run by the user
>"nobody", cgis and server side includes are as well. Up until now, all
>users could execute arbitrary code as user nobody. Nasty. This is a
>gross security risk - basically we were giving you an anonymous account
>to do what you wanted with.

Welllll... an anonymous account that can't really do very much. As you
said, "nobody" has very little access to anything.

>I am not sure at what point user cgis and includes were enabled for user
>pages (It has been like that for a long while now) but they could not
>continue to be. I pointed out this today and the executive acted quickly
>to remove any potential security risk. This meant disabling all cgis and
>includes for the time being.

I think maybe we need to review this decision. I'm not a web expert by any
stroke of the pen but I don't know that we've actually solved our problem.
We may have made it worse:

>However, all is not lost. We are completing the installation of a program
>called cgi-wrap, which runs all cgis as the user who owns the page.

Here's what the WWW Security FAQ said about cgi-wrap:

--
Q37: I hear there's a package called cgiwrap that makes
CGI scripts safe?

This is not quite true. cgiwrap (by Nathan Neulinger <nneul@nospam.umr.edu>, http://www.umr.edu/~cgiwrap) was designed for multi-user sites like university campuses where local users are allowed to create their own scripts. Since CGI scripts run under the server's user ID (e.g. "nobody"), it is difficult under these circumstances for administrators to determine whose script is generating bounced mail, errors in the server log, or annoying messages on other user's screens. There are also security implications when all users' scripts run with the same permissions: one user's script can unintentionally (or intentionally) trash the database maintained by another user's script.

cgiwrap allows you to put a wrapper around CGI scripts so that a user's scripts now run under his own user ID. This policy can be enforced so that users must use cgiwrap in order to execute CGI scripts. Although this simplifies administration and prevents users from interfering with each other, it does put the individual user at tremendous risk. Because his scripts now run with his own permissions, a subverted CGI script can trash his home directory by executing the command

rm -r ~

Worse, since the subverted CGI script has write access to the user's home directory, it could place a trojan horse in the user's directory that will subvert the security of the entire system. The "nobody" user, at least, usually doesn't have write permission anywhere.

--

That doesn't sound like wholehearted enthusiasm on their part to me. In fact, since rogue scripts now run under the permissions of a "full" user, as it says, there may be more potential for damage than when they run under the low-access "nobody" user.

It seems that running as "nobody" just allows people to fuck up other WWW stuff at the worst... so in other words, we'd all have to trust each other that our cgi scripts weren't going to step on our toes. That doesn't sound TOO bad to me, or unworkable. Especially compared to letting cgi scripts destroy your whole directory.

Is the scripts-running-as-nobody really a _security risk_, or just a small hole in absolute tracability?

If so, maybe this doesn't require an "executive decision". Maybe it requires some discussion.

As I said before, could be that I've missed something here. If so, can someone explain it better...

Ryan