A number of php vulnerabilities have been released earlier this week. PHP is a
popular web scripting language, and installed by default in many linux distributions if you install Apache. Versions for Windows are available as well.
For a well written advisory, see: http://www.hardened-php.net/advisories/012004.txt">http://www.hardened-php.net/advisories/012004.txt
The quick solution is to upgrade to the latest version of php, either 4.3.10 if you are using php4 version, or 5.0.3 if you already migrated to php5. Note that the upgrades from 4.x to 5.x may break existing applications. As long as you stay with the major version (4 or 5), the upgrade shouldn't be too hard.
The popularity of PHP, and the possibility of additional bugs, bring up the questions about how to protect your PHP install. As always, if you don't need it, disable it. If you are using php as a module with Apache, look for these lines in your httpd.conf file and comment them out:
These lines will load the actual php module:
The next line will ask php to parse all files with the extension .php. You may find additional extensions listed:
AddType application/x-httpd-php .php
Its probably a good idea to just look for other occurrences of the string "php".
You can limit the use of php to individual virtual hosts, or reduce the list of extensions that are parsed by php to limit your exposure. PHP can also be used as a cgi script. So check your cgi-bin directories for occurrences of the php cgi binary or links to the binary.
Well, now if you need php, like we do here for all the fancy graphs and such ;-), there are a number of ways to keep php a bit more secure:
Probably the most important issue is to turn off 'register_globals'. Recent versions of php turn this parameter off by default. While this doesn't ensure proper variable validation, it encourages it.
A few other things that are a 'must do' IMHO:
(*) look at the various 'magic_quotes' parameters, and enable them as you see fit
(*) in particular if you are administering a machine that is shared by multiple users, become very familiar with 'safe_mode'. But even for a single-use system it is advisable to turn it on if possible (but it will likely break things if you haven't written your scripts to be aware of safe_mode).
(*) while we are on the topic of shared systems: Shared systems are not appropriate for anything else but "entertainment use" ;-). It is quite hard to configure them so users do not interfere with each other (in particular if a web server running needs access to various users files.
(*) review the number of modules you are using. PHP is quite modular, and you can disable various unneeded modules. For example, if you are using MySQL as a database, there is no need to risk exposures from the Sybase or Oracle modules.
(*) Think about permissions. PHP will typically run its scripts as the same user that runs apache (e.g. 'nobody' or 'apache'..). This user has to be able to read the scripts, but it doesn't have to be able to write to these files in many cases.
(*) PHP has to know about dangerous secrets like database passwords. Limit the permissions of the db accounts it uses, and keep the relevant files with passwords outside of the web servers document root.
This is about as much as I can fit into a diary. For some additional references, see the php main site, ( http://www.php.net ), the hardened php site: ( http://www.hardened-php.net ) and well, Google. Of course, don't forget to secure the OS itself.
Anyway. Like guns and fast cars, php can be a lot of fun if used responsibly and with good user input validation.
Johannes Ullrich, jullrich`ATfirstname.lastname@example.org
CTO SANS Internet Storm Center and Handler on Duty.I will be teaching next: Application Security: Securing Web Apps, APIs, and Microservices - SANS London June 2022
Dec 18th 2004
|Thread locked Subscribe||
Dec 18th 2004
1 decade ago