Dangers Presented by Local Users | MySQL and Perl for the Web

only for RuBoard - do not distribute or recompile

The preceding section describes security issues that relate primarily to problems with client users on the remote end of connections to your Web server. However, there are other users you should be concerned about, too. For example, if your Web site runs on a multiple-user operating system such as UNIX and other people have the ability to install Web scripts, there are certain exploits to which you are exposed. First, we ll discuss general issues relating to file system access by other users in particular, access that may be gained through scripts run by Apache. Then we ll cover issues that pertain more specifically to the MySQL server.

Dangers from Other Users with Apache Access

Your general goal with Apache is that it should do the things you want it to, but not anything else. Unfortunately, in a multiple-user situation, other people want Apache to do things, too, and you cannot control their actions. This in itself might not be a problem, except for one thing: Scripts run by Apache have Apache s file system access privileges, no matter who they were written by or who they are owned by. You might write a Web script expecting it to have your own privileges when run under Apache, but that s not how it works. Apache runs with the privileges associated with a specific user and group, and so do any scripts that it executes. This gives all users who can install scripts in the Web tree a certain equivalence. Even if you set the permissions on your Web-related directories and files to keep me out when I m logged in as me, they still must be accessible to Apache. (Otherwise, Apache wouldn t be able to serve your pages or run your scripts.) If I can install a script for the server to execute, it will have Apache s privileges when it runs and thus be able to access any of your Web files. This means that under Apache, I may as well be you for all intents and purposes, because your scripts and mine have the same privileges and my scripts can access anything your scripts can access.

This privilege equivalence of scripts that Apache runs leads to potential problems in the following ways:

Scripts can read files. For files such as HTML documents that are intended to be served to the public by Apache anyway, that is not a problem. However, script file system access is not limited to HTML documents; it also includes the source code for your scripts and libraries, and files in which you might store sensitive information. You probably don t want just anyone reading those files. For example, the ability to read the source code of your scripts might allow another user to figure out interesting exploits to mount against you.
Scripts can write files. Someone else can create (or remove!) files in your Web directories if you don t protect them properly.
Scripts can open connections to database servers. If your scripts read a file to get a MySQL username and password, my scripts can read that file, too. That allows me to open a connection using your MySQL name and password to access your databases. (Put another way, this means you have no secrets from me; your databases are effectively public information.)

Ideally, you will have complete control over your Web server and be the only one with access to it. When you are the only user on your machine, you have fewer file system access issues to be concerned about.^[2] To the extent that other people have accounts on your system and have access to the Web or database servers, you have to consider how much trust you re willing to extend. (That s why full control is ideal; when you have control, you don t need to have trust.) There are at least two important things that should be true before you trust other users who have accounts on the same machine as you:

^[2] That s not to say that there are no file system issues. For example, you ll still want to run Apache under user and group IDs that differ from yours. Then make your Web directories, scripts, and files owned by you and readable to Apache but not writable by Apache. This helps prevent remote exploits that attempt to cause the Web server to create or destroy files on the server host.

You re confident they won t deliberately attack your information.
You re confident about their competence to write secure programs, rather than insecure ones that allow someone else to attack your information.

Some multiple-user situations may be acceptable. A group of developers who all trust each other and are the only ones with server access may be collaborating on a Web-based project and sharing a single server without any problems.

A less acceptable and very possibly unacceptable scenario occurs when a Web server is shared by people with disparate interests and purposes. Examples are academic departments that provide a shared server to handle Web accounts for students and staff, or ISPs that provide Web-hosting accounts using the same server for multiple customers. These scenarios can be very dangerous. Suppose you get an account with an ISP that provides Web hosting. As part of this service, you get your own domain name your-dom.com and a cgi-bin directory owned by you and into which you can install scripts for Apache to execute when clients request URLs of this form:

http://www.your-dom.com/cgi-bin/script.pl

Now if I want to attack you, here s how I do it. I get an account with this same ISP, which gives me my own domain mydom.com and cgi-bin directory and sets them up to be handled by the same server that handles your account. (Such accounts are often billed as virtual servers, but in this case, that means nothing more than your own domain name, hosted on a server that handles a bunch of other people s domain names. )

You can probably set the access permissions on your Web-related directories so that I cannot just log in on the server host and access them directly. However, you must make those directories and their contents available to Apache, and that s all the access I require to create a security breach. I have my own cgi-bin directory, so I just put a script breach.pl there and have Apache execute it by requesting it from my browser like this:

 http://www.my-dom.com/cgi-bin/breach.pl

breach.pl need not be complex or clever. The following listing shows a short implementation that opens a file and displays its contents over the Web. As shown here, breach.pl is set to display itself, but I can easily change that by modifying the value of $file to point at one of your files:

 #! /usr/bin/perl -w  # breach.pl - illustrate a security breach by showing how a Web script  # can display the contents of other Web server-accessible files.  use strict;  use CGI qw(:standard escapeHTML);  # Set $file to the name of the file you want the script to display.  # The setting below causes the script to display its own source code.  my $file = "breach.pl";  print header (), start_html (-title => "Security Breach", -bgcolor => "white");  if (!open (IN, $file))  {     print p (escapeHTML ("Cannot open $file: $!"));  }  else  {     print p (escapeHTML ("Contents of $file:"));      print "<pre>\n";      print escapeHTML ($_) while defined ($_ = <IN>);      print "</pre>\n";      close (IN);  }  print end_html ();  exit (0);

When Apache executes my script, it runs under the same user and group IDs as Apache itself, so I can access your files. How will you stop me? (Or more to the point, ask your service provider how you can stop me.)

Of course, you can mount this same kind of attack against me, too. Unless we trust each other, this arrangement is just a little too cozy. Unfortunately, it s also rather common, and the dangers of this scenario seem not to be very widely appreciated. Note that the problem is not that a single Apache server can handle requests for multiple domains. That s a powerful and important feature. The problem arises from the use of this feature to have the same server handle domains for different people with incompatible interests. (After all, if I own several domains, I can use the same server for all of them without putting myself in danger, because I m not likely to attack myself.)

A shared server can be a source of problems even in the absence of any intent by its users to mistreat each other. All it takes to place everyone at risk is for one person to install a script with an inadvertent security problem that allows an outside attacker to gain access to or destroy information on the server machine.

Security is one of those only as good as the weakest link things; what s the competence level of the other people with whom you share a server? Are you comfortable with that?

mod_perl in a Shared Environment

If you re running a server that is enabled to run mod_perl, you definitely don t want to be operating in a shared-server environment with other untrusted users:

mod_perl scripts can affect the environment in which later scripts run. Malicious scripts can do this deliberately, and poorly written scripts may do it accidentally, but the effect can be the same. (ISPs often won t provide mod_perl in their servers; this is one reason why.)
The mod_perl initialization file is read during the Apache startup process, while Apache is still running as root. Anyone with access to this file effectively has root access. (For example, you can use the initialization file to start up another process that runs as root and that can do whatever you want.)

Limiting Access by Other Users

It s pretty clear from the preceding discussion that you shouldn t run your server as root, because then Web scripts run as root, and anyone who can install a Web script can gain complete access to do anything at all.

To run Apache with the privileges of an ordinary account, use the User and Group directives in the httpd.conf file. For example, to run Apache with the privileges of the user wwwusr and the group wwwgrp, use these directives:

 User wwwusr  Group wwwgrp

The server starts up as root during the system startup process, and then changes the effective user and group IDs to those listed in the configuration file before it starts handling requests. (Naturally, httpd.conf itself should be accessible only to a trusted administrator, otherwise other users may be able to change the User line from wwwusr to root and you ll have no security at all.)

Running Apache as an ordinary user limits the damage it can do, but does not eliminate the problem of other users installing Web scripts that may place your information in danger. Apache version 2.xx provides a general solution to the privilege equivalence problem by allowing specific user and group IDs to be associated with each virtual host. The server can handle requests for you at www.your-dom.com under your user and group IDs, and requests for me at www.my-dom.com under my user and group IDs. This improves server security because it allows you to make your Web scripts and documents accessible only to yourself; that way, other people who share the server can t write scripts that access your files directly. However, Apache 2.xx is not yet in wide use (it just went from alpha to beta as I write), so most sites still run 1.3.xx. In the meantime, other options for running scripts owned by different users under different user IDs include the following:

If the Apache suEXEC feature is available, you can use it to run scripts under your own user ID. This enables you to protect sensitive files so that they cannot be accessed by anyone else s scripts. The cost is some degradation of performance. In addition, suEXEC cannot be used for any application that requires mod_perl, with which it is incompatible. suEXEC also has its own security implications, so you should read its documentation carefully before using it:

http://www.apache.org/docs/suexec.html
You can get your own server. If you re using an ISP, investigate whether that ISP can provide an independent server. The hardware version of this solution involves putting you on your own machine, which can be pricey. A less expensive alternative is the software virtual server, in which the resources of a machine are logically partitioned so as to appear to be multiple separate physical machines. Users in one server cannot access the files in another server, because processes in each partition run under completely independent user and group IDs. ISPs that provide this type of service rightly point out its security advantages over the kind of virtual server that really is only a shared server providing separate domain names. Many ISPs don t like to partition their machines as true virtual servers, though, because the number of server processes becomes a linear function of the number of customers and represents a greater drain on system resources than using shared servers. Therefore, although a virtual server is less expensive than a separate physical machine, it may cost you more than an account on a shared server. Can you afford it? That depends. Can you afford to have your databases be public information, the way they are on a shared server? Ask your ISP what measures are provided to prevent your resources from being accessed illegitimately by other customers. If you don t receive a satisfactory answer, you may need to consider another provider.
If you cannot prevent other people from reading your Web-related files, you should at least try to to prevent people from writing them. Make sure the files are owned by you and located in a directory owned by you. Then change into the directory and turn off the group-write and world-write permissions on the directory and everything under it:
```
 % chmod -R go-w . 
```

For more information about Apache security, a good place to start is, not surprisingly, the security section of the Apache manual:

http://www.apache.org/docs/misc/security_tips.html

Script Location Issues

You may or may not want to keep your Web scripts private from other local users, but you should always keep remote users from looking at them. Whenever possible, put your scripts in directories that are outside the Apache document tree. Directories such as cgi-bin or cgi-perl should not be located anywhere under the document root, because an Apache misconfiguration can allow scripts in the document tree to be retrieved as plain text. If a script contains information such as a MySQL username and password, they ll be visible in plain view. (If you can t keep the script itself out of the document tree, at least encapsulate the database connection call in a library routine and put the library outside the tree.) Exposure of a script s source code may also allow hackers to see how to exploit it (for example, to obtain more information from your database than you intend or to mount denial-of-service attacks) if despite your best efforts the script has a security flaw. Keeping your scripts out of the document tree helps prevent these problems.

MySQL Server Access Issues

All access to database information managed by MySQL goes through the MySQL server, which requires each client to supply a name and password. At least, that s what s supposed to happen. Tables in databases are stored in files, so one possible exploit is to bypass the server entirely and access those files directly. Other problems are MySQL accounts that have not been assigned passwords, or stolen names and passwords. And, just as with Apache, you should limit the powers of the MySQL server by not running it as root. The following instructions illustrate how to enforce some MySQL protection. You ll likely need to run some of the commands shown here as root, because they involve changing file ownerships.

Let s start with the easiest thing first: Run the MySQL server as an ordinary user, not as root. The following instructions describe how to do this. (Before you follow them, you should bring down the server.)

If you want to use an account named mysqlusr, specify the account name in the [mysqld] group of the systemwide MySQL options file /etc/my.cnf :

 [mysqld]  user=mysqlusr

You should also protect /etc/my.cnf so that it can be modified only by root :

 # chown root /etc/my.cnf  # chmod 644 /etc/my.cnf

The file needs to be world-readable because other unprivileged programs may need read access.

Next, protect the MySQL data directory and its contents by limiting access only to mysqlusr. If the data directory is /usr/local/mysql/var, protect it like this:

 # chown -R mysqlusr /usr/local/mysql/var  # chmod -R go-rwx /usr/local/mysql/var

If you restrict access to the data directory as just described so that its contents are available only to your MySQL server, you will have a problem if the server s UNIX domain socket file is located in that directory. (The symptom is that local client connections to localhost will stop working because they no longer can access the socket.) To deal with this, your best bet is to recompile MySQL to place the socket file in a different location. If this is not an option (perhaps you installed MySQL using a binary distribution or from RPM files), open up the data directory enough that client programs can connect to the socket file:

 # chmod go+rx /usr/local/mysql/var

This has the disadvantage that, although it allows MySQL client programs to access the socket file, other users can also run ls to get a listing of the data directory. Because databases hosted by the MySQL server correspond to directories in the data directory, this enables people to find out what databases are available. If you start the server with the --skip-show-database option to restrict people from using the SHOW DATABASES statement, the ability to run ls on the data directory represents an end run around that restriction.

After making the preceding modifications, bring the server back up:

 # safe_mysqld &

The server starts up as root, then finds the user line in the /etc/my.cnf option file and changes its user ID to run as mysqlusr.

To protect your server against unauthorized users connecting to it, make sure each MySQL account has a password. To find any that do not, connect to the server as your MySQL root user to access the mysql database and run this query:

 mysql> SELECT * FROM user WHERE Password = '';

If the query returns any rows, the corresponding accounts are insecure and you ll probably want to remove them or assign passwords to them. (There may be some exceptions. You might, for example, set up a no-password account for use in log file rotation scripts such that the account has only the RELOAD privilege and no access to actual database information. Such accounts should be few and are best allowed to connect only from localhost.)

Are There Other MySQL Superusers?

Earlier in this chapter, we discussed the file system privilege problems that arise if other users have access to Apache. A similar issue comes up with the MySQL server. If other users have MySQL accounts with global (superuser) privileges for the databases managed by the server, your information is accessible to them. Ideally, you should be the only one with such privileges.

Personal MySQL option files used only by yourself can and should be protected. For example, your personal scripts might read connection parameters from the .my.cnf file in your home directory. Make sure no one but you can read this file by using either of the following commands:

 % chmod 600 .my.cnf  % chmod go-rwx .my.cnf

On the other hand, preventing other users from stealing MySQL account names and passwords stored in option files that are accessible to Apache can be a difficult problem to solve. As discussed earlier in Dangers from Other Users with Apache Access, your best option is to operate in an environment with no other Apache users or with only trusted users. If you have parameters stored in a file used by Web scripts, the file can be set to be readable only by yourself and Apache. One way to do this is to have the file be owned by you with group ownership set to the group that Apache runs in. If that group is wwwgrp, the commands to set the ownerships and mode look like this:

 # chown paul filename  # chgrp wwwgrp filename  # chmod g-w,o-rwx filename

The mode setting revokes group-write permission for Apache, and all world-access permissions. This won t keep out people who can install Web scripts, but it will at least prevent everybody else from reading the file.

MySQL accounts that are used by Web scripts should have only the privileges they require. In particular, the FILE privilege gives a MySQL user great power; don t grant it to any account that you use in your Web scripts for connecting to MySQL, at least not without a good reason. The privilege allows a user to read any file on the database host that the MySQL server can read, and allows the user to cause the server to create files on the host in any directory for which the server has write access. This power can be used to hijack information that you may not want leaking out over the Web, or to alter the operation of your system. The potential for damage is multiplied greatly if you run the server as root ; this is one of the reasons to run it as an ordinary user. There may be applications that require the FILE privilege, but make sure you understand the implications before granting it.

For more information about MySQL security, consult the MySQL Reference Manual or a text on MySQL that discusses MySQL administration.

only for RuBoard - do not distribute or recompile