PHP apache_lookup_uri Function bug Analysis

Tornwood

First, let's take a look at the data types defined in PHP:
L-long integer
D-double-precision floating point type
S-string (or NULL bytes) and its length
B-Boolean? R-resource, saved in zval *
A-array, saved in zval *
O-(any class) object, saved in zval *
O-(the object of the class specified by the class entry) is saved in zval *
Z-actual zval *

The bug of apache_lookup_uri is related to the parameter type. The function prototype is as follows:
Object apache_lookup_uri (string $ filename), the function will eventually return an object with the URI Information
This function can easily process resources in the URL. The the_request field in the returned result cannot contain resource characters such as http: //, or tag servers such as <>, otherwise, an error is reported:
Test code:
---------------------------------------
<? Php
Print_r (apache_lookup_uri ($ _ GET [a]);
?>
---------------------------------------
Http: // localhost/server. php? A = Warning: apache_lookup_uri () [function. apache-lookup-uri]: Unable to include But if we submit the variable as an array, what will be returned?
Alert (1)Http: // localhost/server. php? A [] = <script> alert (1) </script>
The code in <script> is executed and the returned result is as follows:
StdClass Object
(
[Status] = & gt; 200
[The_request] => GET/server. php? A [] = <script> alert (1) </script> HTTP/1.1
[Method] => GET
[Mtime] => 0
[Clength] => 0
[Chunked] => 0
[No_cache] => 0
[No_local_copy] => 1
[Unparsed_uri] =>/Array
[Uri] =>/Array
[Filename] => D:/wwwroot/Array
[Path_info] =>
[Allowed] => 0
[Sent_bodyct] => 0
[Bytes_sent] => 0
[Request_time] => 1261465695
)
Because the apache_lookup_uri function itself does not produce output, the risk is relatively small. If the subsequent processing code does not check the returned information of the apache_lookup_uri function, it may cause some security problems, next, let's take a look at the specific implementation of the apache_lookup_uri function:
PHP_FUNCTION (apache_lookup_uri)
{
Request_rec * rr;
Zval ** filename;

If (ZEND_NUM_ARGS ()! = 1 | zend_get_parameters_ex (1, & filename) = FAILURE ){
WRONG_PARAM_COUNT;
}
When defining parameters, the function incorrectly defines filename as the zval type, which allows variable submission as an array.

....
Convert_to_string_ex (filename );

If (! (Rr = php_apache_lookup_uri (Z_STRVAL_PP (filename) TSRMLS_CC ))){
Php_error_docref (NULL TSRMLS_CC, E_WARNING, "Unable to include % s-URI lookup failed", Z_STRVAL_PP (filename ));
RETURN_FALSE;
}
Use convert_to_string_ex to forcibly convert the string, and the Array will be converted to an Array. The returned information of the apache_lookup_uri function can be seen clearly.
[Unparsed_uri] =>/Array
[Uri] =>/Array
[Filename] => D:/wwwroot/Array
At this time, the parameter type is already a string and can be successfully verified by php_apache_lookup_uri.
....
If (rr-> status = HTTP_ OK ){
Object_init (return_value );

ADD_LONG (status );
ADD_STRING (the_request );
ADD_STRING (status_line );
ADD_STRING (method );
ADD_TIME (mtime );
ADD_LONG (clength );
After passing all the check procedures, call object_init to process the returned results. object_init is implemented in/ZEND/zend_API.c.
ZEND_API int _ object_init (zval * arg ZEND_FILE_LINE_DC TSRMLS_DC)
{
Return _ object_init_ex (arg, zend_standard_class_def ZEND_FILE_LINE_RELAY_CC TSRMLS_CC );
}
The parameter type accepted here is also zval. Therefore, the variable values of the previously submitted array type are saved in the returned results. Therefore, the content of the field added to [the_request] can be stored in XSS code, because the apache_lookup_uri function only processes the passed parameter resolution and stores it in an object, it is not prepared to perform content check, so this is not a vulnerability.

The Bug about this function was not found in ChangeLog of PHP. The PHP source code posted in this article is 5.2.11/12. Then I read the code of 5.3.1, this small bug has been removed and is handled as follows:
Php-5.3.1sapiapache2handlerphp_functions.c
----- Line: 118-> 126 ------
PHP_FUNCTION (apache_lookup_uri)
{
Request_rec * rr;
Char * filename;
Int filename_len;

If (zend_parse_parameters (ZEND_NUM_ARGS () TSRMLS_CC, "s", & filename, & filename_len) = FAILURE ){
Return;
}
......
We can see that the parameter type has been clearly defined as a string, and the parameter is obtained by specifying "s" through the zend_parse_parameters function.
Zend_parse_parameters () tries to convert the parameter type while parsing the parameter, so that we can always get the expected type of variable. Any scalar type can be converted to another scalar type, but cannot be converted between a scalar type and a complex type. In this case, if you submit the variable as an array, a warning error will be returned:
Warning: expects parameter 1 to be string, array given in ....
The process is roughly as follows:
Zend_parse_parameters-> zend_parse_va_args->
If (! Quiet ){
Zend_function * active_function = EG (function_state_ptr)-> function;
Char * class_name = active_function-> common. scope? Active_function-> common. scope-> name :"";
Zend_error (E_WARNING, "% s () expects % s % d parameter % s, % d given ",
Class_name,
Class_name [0]? "::":"",
Get_active_function_name (TSRMLS_C ),
Min_num_args = max_num_args? "Exactly": num_args <min_num_args? "At least": "at most ",
Num_args <min_num_args? Min_num_args: max_num_args,
(Num_args <min_num_args? Min_num_args: max_num_args) = 1? "": "S ",
Num_args );
}
Return FAILURE;

Finally, I found that the error prompt was changed directly in PHP5.3.1:
Zend_error (E_WARNING, "% s (): bad type specifier while parsing parameters "....