Third-party PHP
find vulnerabilities in them, so everything should be inspected. For example, if the server runs a third-party PHP version, everything can prove more serious.
There are a number of third-party PHP versions currently in use. All of them were created to increase the performance and functionality of the language. A third-party PHP version increases the average operating speed of the application up to 5 times, which is definitely a lot. This is a result of cross compilation. In general terms, compilation consists in two steps:
• The PHP script is translated into intermediate code (as a rule, the C code);
• The C code is compiled into machine code.
Yet, the best way to understand the process is to skip the general and look at each version one by
one.
Overview of Alternative PHP Versions
Roadsend PHP
The first version to be considered is PHP Roadsend. In its essence, it consists of two components:
a compiler and an integrated web server called MicroServer.
The compilation involves an intermediate translation of PHP code into C code.
The embedded web server allows starting the compiled applications without any additional addons
or tools. Otherwise, the application has to be connected to a web server (such as Apache, lighttp,
nginx, etc.) via the cgi or fastcgi.
Phalanger
Next PHP version, Phalanger, is of a particular
Phalanger works with the IIS web server; their integration is as simple as in the case of the original PHP version.
Quercus on Resin
Another example of a good combination of technologies is the Resin web server. Its first versions
served as a web server and as a server for Java applications, but then they released a PHP version
called Quercus.
Resin has two branches: Resin Professional and Resin Open Source. In Resin Professional, PHP
code is compiled into Java code, while in Resin Open Source, PHP code is interpreted.
HipHop for PHP
Finally, there is HipHop for PHP developed by Facebook. HipHop transforms PHP source code
into C++ and then compiles an executable file using g++.
It should be mentioned that the size of an application compiled by HopHop, even a simple one,
reaches 30 Mb. However, the application already includes a web server: just specify the corresponding key and an access port when starting it. Besides, as in the case of Roadsend PHP, the
compiled application can connect to web servers via cgi or fastcgi.
Compilation takes much time, so, if the application is constantly modified, updating can turn into
a nightmare.
Yet, there is a good side, as well. HipHop excludes certain types of vulnerabilities:
• Local File Inclusion – it includes only files it contains at the moment of compilation;
• Arbitrary File Upload – it doesn't use uploaded files as they are not executable and interpreter
is not used.
Peculiarities
So, we are facing a task to detect security flaws in a number of new languages at once. They have
syntax similar that of the original PHP, but does it imply similar results, behavior and peculiarities?
Even more so, how dangerous could third-party versions be? To find it all out, we are to know how
we can compare them and what we should consider.
It seems reasonable to work out a number of criteria to compare the versions:
• Context vulnerabilities: almost all the versions have embedded web servers and other context
tools integral for any web application;
• Mechanisms of parameter processing : think of such attacks as HTTP Parameter Pollution and
HTTP Parameter Contamination and consider variability glottalization and typification;
• Vulnerabilities on the boundaries of technologies: new functions can create new vulnerabilities;
• Vulnerabilities typical of earlier PHP versions.
Context Vulnerabilities
The leader in this category is Roadsend PHP, or rather, its MicroServer web server, which is able
to a simple variant of Path Traversal. A possible exploitation is provided in Listing 1.
As you can see in the request, everything is simple – Roadsend PHP uses redirection to the parent
directory and applies the URL encoding to the slash symbol. As a result, you can get content of
any file. However, in this case there is an easier way of exploitation – by specifying the absolute
path to the file (see Listing 2 and Figure 1).
The Roadsend PHP project is not supported any more, though there are some resources that
still use it. Owners of such resources are strongly advised to switch to an alternative product.
Parameter Processing
HTTP Parameter Contamination
As it is generally known, different platforms and applications use different approaches to process
predeterminedly incorrect characters and constructions: some substitute such characters, others
don't. This is what the HTTP Parameter Contamination attack is based on. Usually, it is used
to bypass all sorts of filtering mechanisms and to form peculiar vectors of client-side attacks.
Table 1 and Table 2 illustrate the difference in approaches to incorrect character processing for various PHP versions (compared to a standard LAMP as the model).
The result is evidently different from that in the original PHP. It's notable that the deviations are almost identical for Phalanger and Quercus. Apart from the possibility to create variables with a blank line as name, in both cases you can provoke error 500 (see a funny fingerprint in Figure 2).
A possibility to create variables containing the gap char or even a null-byte in their names will affect
looping through arrays (see Listing 3), when it uses not only the value of the variable, but its
name as well.
In the above code, the variable name is transmitted to the construction that includes scripts. Using
null-byte in the variable name, you can omit a part of the line and include an arbitrary file (see Listing 4).
Globalizing And Overriding Variables
A possibility to assign variabilities directly creates a a flaw in the application's security. In the original PHP, it is performed by means of register_globals, yet, starting from version 5.4.0 this option is deleted.
It seems reasonable that the third-party PHP versions are not that impeccable as we could wish for.
The Quercus does nnot provide the option (the developers call it "a black hole of security"). However, when the parameters are sent by the POST method, they are globalized, which is not supposed to happen if the option is absent.
But this is not the main problem. The real danger is that parameters sent via the POST method can
override elements of the _SERVER array. Figure Figure 3 illustrates overridden value of the element of _SERVER["REMOTE_ADDR"], which, in itself, leads to IP address spoofing. The most destructive attack vector is spoofing the value of the $_SERVER["DOCUMENT_ROOT"] element that contains an absolute path to the web catalog and development of the Local File Inclusion attack (see Figure 4). It's worth mentioning that even a code that is secure for the original PHP (see Listing 5) becomes vulnerable if there is a possibility to override variables.
The vulnerability is described in advisory. http://www.ptsecurity.com/lab/advisory/. The vulnerability
is expected to be fixed in the subsequent versions.
A curious fact is that you cannot override elements of the _SESSION array. Any attempt to override
them leads to an error. But it's for the best, because otherwise it will make any authorization
mechanism that uses the _SESSION vulnerable.
Typification of Vulnerabilities
PHP provides for a so-called flexible comparison that allows matching variables of distinct types
(identical congruence of variables of distinct types always results in "false"). The process of comparison has its peculiarities that are summarized in a table provided on the official web site: http://ru2.php.net/manual/en/types.comparisons.php. If these peculiarities are not observed, the results of operation of the application might be unpredictable.
Differences with the original PHP were fast to find. The scripts provided in Listing 6 and Listing 7
execute comparison between an empty array and variables of distinct types.
The scripts differ in the sequence order of the variables being matched, but otherwise are identical.
So, the results must coincide as well.
However, as it is evident in Table 3, the Quercus shows the results according to the sequence order
of the matched variables.
Besides the above correlation, the comparison of an empty array() and 0 results in "true", which is
also untypical of the original PHP. This can facilitate bypassing various checks such as authentication
or authorization.
Vulnerabilities of Technological Boundaries
PHP is known for its feasibility to set various security restrictions. For example, its disavle_functions
prohibits to call specified functions (as a rule, those executing shell commands), while open_
basedir restricts access to the file system.
But usually the possibility to use third-party constructions is disregarded (see Listing 8).
So, by using .NET constructions for execution of shell commands, one can bypass the given security
restriction. Such bypass is illustrated in Listing 9.
Old School
Cross-Site Scripting in Error Messages
Roadsend PHP and Quercus have distinguished themselves with their error messages, where the
service characters are not substituted for their HTML equivalents, which can facilitate attacks on users of the site (see Figure 5).
The developers must have forgotten that it's 2012 we are living in, not 2002
Path Traversal in Names of Downloaded Files
Quercus, which is a part of the third branch of the Resin web server, is vulnerable to Path Traversal in
the mechanism that downloads files to the server. Paths to the parent directory are not deleted from
the file names. As the result, a file can be downloaded to an arbitrary catalog (see Listing 10).
The description of vulnerabilities is provided in advisory: http://www.ptsecurity.com/lab/advisory/.
The vulnerabilities are expected to be fixed in next verions.
Null-Byte in Names of Downloaded Files
Path Traversal is not the only problem with file download in Quercus. Another danger is a possibility
to send a null-byte in a file name, which allows cutting off a compulsory postfix of a file name
(for example, .jpg) and bypassing certain security checks (Figure 6).
A by-passible check is illustrated in Listing 11. The given script demonstrates a check of a file
extension: it should be one of the permitted extensions (jpg, png or gif), otherwise the file won't be
downloaded. The check itself is quite efficient, but using a null-byte in the file name you can easily
bypass the check: send a null-byte and then, .jpg. Thus, the check will be bypassed. The .jpg postfix
will be cut off while the file is being copied.
The description of vulnerabilities is provided in advisory: http://www.ptsecurity.com/lab/advisory/.
The vulnerabilities are expected to be fixed in next verions.
Conclusions
All the versions considered in the article are way more efficient than the original (up to 5 times), but
almost all of them have security faults:
• Vulnerable environment
• Faults in parameter processing (globalization, typization)
• Various types of logical corruption
• Various types of Path Traversal
• etc.
The above vulnerabilities make even a secure application vulnerable if third-party PHP versions
are used. A perfect example is Quercus, that proved most vulnerable of all considered in this article.
However, there is an exception – HipHop, by certain criteria, is even more secure than the original
PHP.