Securing your community

[IPS News]

There has been much confusion over the recent exploit reported to us and subsequently patched. I would like to personally apologize for any confusion and inconvenience caused. We have conducted a review and made appropriate changes to our policies to ensure a smoother release and notification schedule for any future incidents.

 

With that said, it is very important to note that while an IP.Board vulnerability did exist, its impact would have been minimal, if not non-existent on servers that have their PHP installations properly secured. I would like to touch on a couple of basics to minimize the effects of future vulnerabilities not only in IP.Board, but any other PHP application you may be using on your website.

 

open_basedir

 

It's very important that you (if you manage your own web hosting server) or your web host enable open_basedir. In a shared hosting environment without open_basedir, an attacker has the ability to exploit a vulnerability, perhaps on another customer's account, then use that vulnerability to scan for other customers on the server. From there, they could gain access to config files containing database details, write malicious files to world-writeable directories and a host of other ill-willed activities. Enabling open_basedir "locks" all internal PHP functions such as readfile() to the specified path, which is generally a temporary directory and your home directory.

 

disable_functions

 

While open_basedir is a very positive step in securing your PHP scripts, there are unfortunately instances in which it can be bypassed and this is how the recent IP.Board vulnerability gained ground so quickly. For example, the exec(), system() and passthru() functions allow a command to be issued directly to the operating system to view key system files, navigate through other users' web root directories, install 'remote shell' scripts into other users' directories, etc. without any regard to other restrictions such as open_basedir. For this reason, disable_functions should be set to disable system level functions. For example, this is a recommended disable_functions:

 

disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system

You or your host may need to tweak to suit, but at a minimum, execution commands should be disabled.

 

 

Following the above, you will not necessarily create a fool-proof environment, but you will have additional reassurances that you or your host have taken appropriate measures to better secure your PHP applications.

 

 

For those that run a cPanel/WHM server you may enable open_basedir by visiting WHM and clicking the "PHP open_basedir Tweak" link under "Security Center" then clicking enable.

 

 

 

You may modify the disable_functions line by visiting WHM and clicking "PHP Configuration Editor" under "Service Configuration" then clicking "advanced" and searching for "disable_functions"

 

 

 

 

If you are unsure or do not have the necessary permissions to carry out these tasks, please do contact your host. You are free to link them to this blog entry as well.

 

I hope this helps better explain the recent security concern and what you can do to help protect yourself and your users in the future. As always, please feel free to contact us with any questions or concerns you might have. Thank you for your cooperation and understanding.

 

View the full article

 

View the full article