Help:Security

From GRWiktionaryHelp

This guide is incomplete, but should serve as an introduction to some of the areas where an administrator might want to tighten up server security. Some of the advice here is geared towards people who are familiar with web server configuration and are running large servers. If you get lost in some of that, don't worry! The general notes apply to all.

Contents 1 Stay up to date 2 General PHP recommendations 3 General MySQL recommendations 4 Manual installation 5 Alternate file layout 6 User security 7 Upload security 8 External programs 9 Fixes for past vulnerabilities

Stay up to date

The most important security step you can take is to keep your software up to date. Both MediaWiki and the software it depends on will occasionally produce new versions correcting newly-discovered security vulnerabilities which may affect you.

I would strongly recommend that anyone running MediaWiki subscribe to the mediawiki-announce mailing list. This is a low-traffic list that sends out only new version announcements.

At this time (June 2005) we're still making security update releases for the 1.3.x and 1.4.x branches, and 1.5.x is nearing its public release.

If you're running the latest 1.3 or 1.4 you should be reasonably secure, insofar as they don't contain any vulnerabilities that we know about and the default configuration should not be unnecessarily unsafe. If you're running an older version, or any 1.2.x or older version, there may be problems that could affect you and you should strongly consider upgrading.

Don't forget to also keep up with updates to Apache, PHP, MySQL, and any other software running on your servers -- both the operating system and other web applications. Several peoples' MediaWiki 1.3.x installations were affected in Fall 2004 by a worm attacking a flaw in PHPbb; once it had gotten in through other customers' unpatched PHPbb sites it added a "you are hacked" message to other writable .php files on the system, including the compiled templates that MediaWiki 1.3 used.

General PHP recommendations

These bits of advice go for pretty much any PHP environment, and are not necessarily specific to MediaWiki.

PHP configuration recommendations, for php.ini or set otherwise:

• Disable register_globals.
  • Many PHP security attacks are based on injection of global variable values, so making sure it's off can make many potential vulnerabilities toothless.
  • If you require register_globals for another web application, consider enabling it selectively, only for the virtual host or subdirectory that requires it.
  • MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerabilities.
• Unless you require it specifically, disable allow_url_fopen.
  • Remote PHP code execution vulnerabilities may depend on being able to inject an URL into an include() or require(). If you don't require the use of remote file loading, turning this off can prevent attacks of this kind on vulnerable code.
  • MediaWiki may require this setting to be on for the Lucene search extension, the OAI harvester extension, and certain uses of Special:Import in 1.5. It should not however be required in a typical installation.
  • MediaWiki should be safe even if this is on; turning this off is a precaution against the possibility of unknown vulnerability.
• Set session.use_trans_sid off.
  • If this is on, session IDs may be added to URLs sometimes if cookies aren't doing their thing. That can leak login session data to third-party sites through referer data or cut-and-paste of links.
  • You should always turn this off if it's on.

Your php.ini may be located in:

• /etc/php.ini (Red Hat Linux, SuSE / Novell Linux)
• /etc/php4/apache/php.ini (Debian woody and sarge)
• /usr/local/php/lib/php.ini (Mac OS X using Marc Liyanage's PHP package)
• /var/www/conf/php.ini (OpenBSD)
• /usr/local/etc/php.ini (FreeBSD)
• Gentoo Linux:
  • /etc/php/apache2-php4/php.ini
  • /etc/php/cli-php4/php.ini
  • /etc/apache2/php.ini
• c:\windows\php.ini (Windows)

For instance if you see this line in php.ini:

register_globals = On

Change it to:

register_globals = Off

Alternatively, you could add this apache directive to turn off register_globals on a per-directory basis:

php_flag register_globals off

Then restart Apache to reload the changes (apachectl reload).

On a multiuser system with PHP installed as an Apache module, all users' scripts will run under the same reduced-privilege user account. This may give other users access to read your configuration files (including database passwords), read and modify your login session data, or write files into your upload directory (if enabled).

For multiuser security, consider using a CGI/FastCGI configuration in which each user's scripts run under their own account, or enabling Safe Mode to limit script access to other users' files. Note that safe mode may interfere with some features of MediaWiki such as uploading and extensions which shell out to other programs.

General MySQL recommendations

In general, you should keep access to your MySQL database to a minimum. If it will only be used from the single machine it's running on, consider disabling networking support so the server can only communicate with local clients over Unix domain sockets.

If it will be used over a network with a limited number of client machines, consider setting the IP firewall rules to accept access to TCP port 3306 (MySQL's port) only from those machines or only from your local subnet, and reject all accesses from the larger internet. This can help prevent accidentally opening access to your server due to some unknown flaw in MySQL, a mistakenly set overbroad GRANT, or a leaked password.

If you create a new MySQL user for MediaWiki through MediaWiki's installer, somewhat liberal access is granted to it to ensure that it will work from a second server as well as a local one. You might consider manually narrowing this or establishing the user account yourself with custom permissions from just the places you need.

Note that the user table in MediaWiki's database contains hashed user passwords and may contain user e-mail addresses, and should generally be considered private data.

See:

• mysql command-line options --skip-networking
• GRANT and REVOKE syntax

Manual installation

If you use the web-based installer, you may be vulnerable to attack by somebody else running the installer on your server between the time you make the config directory writable and the time the LocalSettings.php file is written out.

Usually this should not be a very large risk, but if it's unacceptable to you (or if you need to do a batch install of many wikis), consider doing an installation manually:

• Create a database
• Grant user permissions
• Source maintenance/tables.sql to create the tables.
• Create a LocalSettings.php based on a sample or the generation code in config/index.php, and AdminSettings.php based on AdminSettings.sample
• cd maintenance && php update.php

If PHP is running as an Apache module, the LocalSettings.php generated by the web installer will usually be owned by the Apache user account. To ensure that it can't be changed again by another user (see notes above about multiuser systems) or by malicious code injected to a vulnerable web application, you should reassign it to another account. (If you have only limited access, consider copying instead of moving the file; the new copy will be under your other account.)

Alternate file layout

MediaWiki is designed to run in-place after being extracted from the distribution archive, for ease of installation.

You can however manually consolidate or relocate various files, to avoid duplicates in a mass installation or to keep sensitive files out of the web root for safety.

(Moving the main includes and skin files may require carefully picking and choosing and altering the include_path set in your LocalSettings.php. Experiment with this as desired.)

Consider moving the database password or other potentially sensitive data from LocalSettings.php to another file located outside of the web document root, and include()ing that file from LocalSettings.php. This can help to ensure that your database password will not be compromised if a web server configuration error disables PHP execution and reveals the file's source text.

Similarly, editing LocalSettings.php with some text editors will leave a backup file in the same directory with an altered file extension, causing the copy to be served as plain text if someone requests eg LocalSettings.php~. If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.

User security

Someone able to edit the user-interface messages in the MediaWiki: namespace can introduce arbitrary HTML and JavaScript code into page output. This means wiki user accounts with the 'sysop' permission, as well as anyone with direct write access to the cur table in the database.

Malicious attacks here could be used to snarf users' passwords as they login, or to attempt to exploit browser vulnerabilities (install spyware, etc). So, you should make sure that only trusted people have these permissions.

Also, don't forget to delete the config directory of each MediaWiki installation after installation is complete. Otherwise users could access the config scripts and damage the installation.

Upload security

File uploads are an optional feature of MediaWiki and are disabled by default. If you enable them, you also need to provide a directory in the web root which is writable by the web server user.

This has several implications for security:

• The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory (see multiuser notes above)
• While PHP's configuration sets a filesize limit on individual uploads, MediaWiki doesn't set any limit on total uploads. A malicious (or overzealous) visitor could fill up a disk partition by shoving lots and lots of uploads at you.
• Generated thumbnails and uploaded files held for overwrite confirmation may be kept in images/thumb and images/tmp without visible notice in the MediaWiki web interface. Keep an eye on their sizes as well.

The default configuration makes an attempt to limit the types of files which can be uploaded for safety:

• By default, file extensions .png, .gif, and .jpg are whitelisted.
• Various executable and script extensions are explicitly blacklisted even if you disable the whitelist.
• Multiple file extensions are checked against the blacklist.
• Several known image file extensions have their types verified using PHP's getimagesize function.
• Uploaded files are checked to see if they could trip filetype detection bugs in Internet Explorer and Safari which might cause them to display as HTML.

In case these checks turn out to be insufficient, you can gain further protection by explicitly disabling server-side execution of PHP scripts (and any other scripting types you may have) in the uploads directory (by default, images).

For instance, an Apache .conf file fragment to do this if your MediaWiki instance is in /Library/MediaWiki/web might look something like:

<Directory "/Library/MediaWiki/web/images">
   # Ignore .htaccess files
   AllowOverride None
   
   # Serve HTML as plaintext, don't execute SHTML
   AddType text/plain .html .htm .shtml
   
   # Don't run arbitrary PHP code.
   php_admin_flag engine off
   
   # If you've other scripting languages, disable them too.
</Directory>

Your exact configuration may vary.

Note that use of PHP's safe mode or open_basedir options may complicate handling of uploads.

External programs

• /usr/bin/diff3 may be executed for edit conflict merging.
• If ImageMagick support for thumbnails or SVG images is enabled, convert may be run on uploaded files.
• If enabled, the texvc math extension will call texvc executable, which calls latex, dvips, and convert (which calls gs).

Fixes for past vulnerabilities

If you are running an older-than-current version of either the 1.4 or 1.3 branches, or a 1.2 or older release, you should upgrade immediately:

• 1.4.5: fixes template HTML JavaScript injection
• 1.4.2: fixes JavaScript injection if $wgUseTidy on

• 1.3.13: fixes template HTML JavaScript injection
• 1.3.12: fixes JavaScript injection if $wgUseTidy on
• 1.3.11: fixes several XSS injections, introduces protection against offsite form submission forgery, fixes directory traversal in image deletion
• 1.3.10: fixes XSS injection, partial protection against offsite form submission forgery; user JavaScript now disabled by default
• 1.3.9: fix to upload file extension blacklisting if whitelist is too wide is disabled; possible PHP code injection on vulnernable configurations
• 1.3.7: fixes a bug in handling of protected pages
• 1.3.4: added upload checks for HTML/JavaScript injection

The 1.2 branch has been discontinued. It's known to contain the template HTML JavaScript injection vulnerability and may contain other problems; upgrading to a current release is strongly recommended.