Some instructions on PHP security configuration Bypass

A vulnerability was released a few days ago: PHP safe_mode and other security configuration bypass: http://www.bkjia.com/Article/201302/188083.html Here are some interesting things to explain. 1. This is not a new problem. It is actually the "PHP FastCGI remote exploitation" I posted last year. The only problem last year was remote exploitation. The administrator needs to configure it on the Internet. At that time, this problem was submitted to the official PHP team. The official team thought it was a personal configuration error and there was no need to fix it. I also admit this, but the official website did not pay attention to the nature of the problem. In fact, this is a vulnerability caused by the combination of the two problems. One is that fpm itself does not know whether the other side that initiates the request is actually a webserver, the other is that fpm allows you to pass parameters in this request to modify php. ini configuration. So this time I changed the scenario, that is, on the cloud platform or other shared host platforms, the script submitted by the customer is allowed to run. Although this fcgi is on port 9000 of the local machine, this issue can also be used to bypass the safe_mode/open_basedir restrictions that originally imposed security restrictions. 2. disable_functions/disable_classes cannot be bypassed through this method. This issue was originally intended to be stated when the vulnerability was submitted. However, after modifying the vulnerability, I do not know why wooyun did not pass the review. Therefore, this description is not added to the current version. In the php-fpm.conf, we can see a passage like this:; Defining 'Disable _ functions' or 'Disable _ classes 'will not; overwrite previusly defined php. ini values, but will append the new value; instead. that is to say, if you modify the value of disable_functions/disable_classes through fpm, it will not overwrite the original configuration, but disable the function or class you added based on the original configuration. Is it possible for PHP to impose restrictions on security issues in advance? Actually, this is not the case. This is related to the implementation of disable_functions/disable_classes. If you are willing to read the PHP source code, you will find that in the php implementation, both built-in functions and built-in classes actually maintain two hash lists in the memory, storing the address of the function. When the php process starts running, it reads the configuration of php. ini. In this case, the corresponding content will be deleted from the hash list of functions and classes according to the configuration of disable_functions/disable_classes. ZEND_API int functions (char * function_name, uint function_name_length TSRMLS_DC)/* {*/{if (functions (CG (function_table), function_name, function_name_length + 1) = FAILURE) {return FAILURE;} disabled_function [0]. fname = function_name; return zend_register_functions (NULL, disabled_function, CG (function_table), MODULE_PERSISTENT TSRMLS_CC);} If you subsequently modify disabl using methods such as php_value of fpm The value of e_functions/disable_classes. At this time, the original function has been deleted and cannot be restored. Therefore, the new value can only be appended, instead of "Restore. 3. As I said in 1, the essence of this problem is that "fpm itself does not know whether the other party initiating the request is actually a webserver" and "fpm allows php to pass parameters through this request. configuration in ini ". Therefore, this is actually an architecture issue. The fcgi daemon and webserver are separated to improve the scalability of the architecture and facilitate the separation and expansion of the frontend cluster and the backend PHP parsing cluster, this kind of architecture will inevitably have the price of mutual ignorance and trust between the two ends (the previous memcached is actually a similar architecture and problem ). I have thought about this vulnerability when I discovered it. If PHP needs to fix this vulnerability, either it can only restrict the fcgi parameter to modify the php. ini function or the parameters that can be modified in the whitelist. However, this is a temporary solution and can only solve one problem. Another problem is that "fpm itself does not know whether the other party initiating the request is actually a webserver". The best solution is to implement webserver authentication in fpm. The request source is webserver. However, this involves modifying the fastcgi protocol, and the protocol itself is not something that php officials can interfere. Therefore, this may be a dilemma. So after I submitted this question to the official website, I saw the fat solution, which is either of the two methods. But does it really work? We will wait and see. 4. The exp used in the vulnerability will be suspended. After submitting the code to the official website, it seems that this time the official website is willing to fix it. Therefore, the exp code used will not be published for the moment. Wait until the final processing method is officially announced.