Here are some screenshots how the PHP bytecode of FluxBB 1.2.20 looks like in Binnavi.

First screen shows the project overview window. So far 281 PHP functions were identified. This includes those defined within fluxBB, those called in fluxBB and one virtual main function for every PHP file.

The second screenshot shows a part of the native callgraph within FluxBB.

The last screenshot shows a part of the code flow graph (CFG) of the handle_url_tag function defined in FluxBB.

Now that php2sql finally works with Binnavi 2.0 it is time to convert my PHP decompiler and code scanner to Binnavi 2.0 plugins. I will keep you updated.

However rescue is near in the form of a USB device that allows you to enter the backslash character in a smooth and easy way. First pictures of this device that will be available at shop.php.net around christmas have leaked to the internet.

This should finally shut up all the namespace seperator critics and allow the PHP developers to finally release the long awaited PHP 5.3

Being a man of actions the first thing I did today was to fork PHP.

Proof is here.

The meeting takes place at Hallmackenreuther, Brüsseler Platz 9, 50674 Köln (Google Maps)

Everyone working in the field of information security is invited to attend. To find us, just ask for the tables reserved for CGNSec.

There is a FreeBSD kernel developer Stefan Eßer (Esser) that is also from cologne and also works in the field of IT-Security. We are not the same person and I am not related to him in any way, however he is of course invited to join us at CGNSec next month.

Ahh yes… I am also not related to that other Stefan Esser that writes books about Witches.

Everyone working in the field of information security is invited to come.

Because it is the first meeting we still have to elaborate how scalable the location will be. I therefore recommend dropping a mail to me until tuesday night if you want to attend so that we can reserve enough seats.

The first questions they often ask themself are:

• Did they trigger a bug in Suhosin?

• Is something wrong with Suhosin?

In reality this means that when PHP internally tried to free some allocated memory the memory manager security features of Suhosin detected that the memory to be freed is somehow corrupted. This corruption occured somewhen between the allocation of the memory area and the attempt to free it. Suhosin detects this by writing canary values infront and after allocated memory areas. These canary values are random numbers that are stored in one of Suhosin’s internal variables. The check consists of comparing the internally stored random number with the values found infront and after the memory area. Those values are outside of anything PHP is supposed to write to and therefore a failed canary comparision can only mean two things.

1. some memory corruption destroyed/overwrote the internally stored random values
2. some memory corruption destroyed/overwrote the canaries next to the allocated memory

This means everytime Suhosin gives out an error there was a memory corruption. There are no false positives as some of the PHP developers claim again and again. This means that everytime you see this error there has been a memory corruption in PHP or one of the loaded extensions. This means there is a bug and some code in one of the loaded components that behaves wrongly.

Unfortunately the PHP developers refuse to support PHP users that decided to go with the more secure version of PHP, because the patch could influence how PHP works and be the cause of the bug. They require their users to reproduce the problem with a vanilla PHP with valgrind running.

The obvious problems with this are

1. Running PHP in valgrind has a much greater influence on how PHP works than Suhosin-Patch has
2. Using valgrind wrongly means the memory corruption bugs cannot be found
3. Using valgrind correctly does not necessary reveal the bug, because it might be hidden by memory alignment or just because valgrind cannot detect that class of memory corruptions
4. A memory corruption that Suhosin might detect everytime might only crash a vanilla (valgrind) PHP once every thousand invocations or might not result in a crash at all but in wrong computation results
5. Some memory corruptions occur in memory areas that are unused due to alignment, they will not result in misbehaviour of vanilla PHP - However any memory corruption is a bug in PHP (or extensions) that should be fixed and a little harmless memory corruption today could turn into a remote exploit in the future when the code is changed (or when PHP is executed on another (new) architecture).
6. A normal user will not be able to recompile PHP and reproduce with valgrind correctly
7. A not reproduced memory corruption still exists but will not be fixed

That said the only option for users of the more secure PHP is at the moment to try to get support for their problem at their distribution’s PHP maintainers because the people at PHP.net will not be interested in helping them. However due to the reasons above the distribution maintainers might not be able to help you, because they cannot reproduce the bug (although Suhosin proved its existance).

If you know what you are doing then just use valgrind on the Suhosin patched PHP and simply claim that you reproduced the bug without Suhosin installed. This will also give you a higher probability of reproducing the problem.

Because of this I will think up some debugging functionality for Suhosin that will make it easier for users to tell the PHP developers where their bug is located. More information about how this will be implemented will be released during the next month.

One of these small changes is the introduction of a new php ini directive called request_order. request_order is the response of the PHP developers to me preaching for years that using $_REQUEST is not only deprecated but actually dangerous for PHP applications. With request_order it is now possible to control in what order $_REQUEST is created and what variable sources are taken into account. This finally allows removing cookie data from $_REQUEST without removing them from $_COOKIE also.

Because removing cookies from $_REQUEST might break badly written software request_order is not set by default. However the recommended setting by the PHP developer is to set it to “GP” which means only $_GET and _POST data is merged into $_REQUEST with $_POST data overwriting $_GET data.

To learn why using $_REQUEST is a bad idea and what Delayed Cross Site Request Forgeries/Hijacking are continue reading…

$_REQUEST and Cookies

PHP application developers often use $_REQUEST instead of $_GET or $_POST because they do not care about the source of input. This has been considered bad practice for a while, because it is actually a violation of the idea behind GET and POST requests: GET is meant to retrieve data, POST is meant to manipulate data. And others have wrongly claimed that using POST instead of GET is a protection against CSRF. Nevertheless PHP application developers still use $_REQUEST a lot, because they cannot see the security threat in using it.

What most of them forget is that $_REQUEST does also contain $_COOKIE data and cookies unlike $_GET and $_POST data are shared among a (sub-)domain. So an application must actually expect that there might be cookies alien to the application. These cookies could be an attack on the application but aren’t necessary. However their presence in $_REQUEST results in application input filters going crazy or they might influence the application logic.

Therefore it is important to remember that cookies might be legal cookies of another application on the same host. And it is also important to remember that some browsers like Firefox 2 does allow an application to set cookies valid for a whole country if the domain is like *.co.uk or *.co.kr. While this allows cross domain user tracking, it also means any application in the country could set a cookie that is seen by your application and considered an attack.

Cookie Denial of Service (DOS)

Taking this into account it should be obvious that any application blocking requests because of some value appearing in $_COOKIE or $_REQUEST is vulnerable to denial of service. Once an attacker is able to get a cookie into the browser of a user, which is possible through XSS in one application on the same domain or cross domain vulnerabilities in browsers, it will trigger the request blocking in the application with every request. The user will not be able to use the application anymore unless the cookie expires or he manually deletes it. However the average user does not have a clue how to delete a cookie, which means he will be denied access forever.

NOTE: Due to PHP’s way of ignoring trailing spaces in variable names and because cookies might be set (sub-)domain wide or path wide, it is not possible for the application to kill the cookie by issuing a simple Set-Cookie HTTP header.

Many open source PHP applications are vulnerable to Cookie Denial of Service because they introduced code similar to the following example to protect against PHP’s GLOBALS overwrite problem.

if (isset($_REQUEST['GLOBALS'])) {
   die("GLOBALS Overwrite attack attempt!!!");
}

Because of this it is possible to deny a user access to a lot of sites in Korea or the UK by just creating a GLOBALS=1 cookie for *.co.kr/*.co.uk in older Firefox versions. Another attack that hits many PHP applications is creating a cookie called action=logout.

Delayed Cross Site Request Forgeries/Hijacking

When $_REQUEST is used by an application to react on user input instead of just $_GET or $_POST an attacker can inject certain values or actions into an application through injected cookie data instead of just killing it with a Cookie DOS. This attack is similar to a Cross Site Request Forgery with the difference that it actually hijacks a user request instead of simply forging it and that it happens with a delay: After the cookie is injected the CSRF is executed the next time the user uses the site.

Because the actual attack relies on hijacking an actual user request that is abused by manipulating by adding or modifying some input variables people might prefer to call it Cross Site Request Hijacking. It is important to realise that a delayed hijacking is different from just forging the request. This also means that traditional CSRF protections like form tokens or asking the user for his password are ineffective against this kind of attack. Because the attack just changes some of the variables within a request the secret form tokens and/or user submitted passwords of the original request will be transmitted correctly.

A vulnerability like this was found and disclosed in phpMyAdmin a while ago. Within phpMyAdmin it was possible to inject a cookie that would execute arbitrary SQL statements on the server the next the user logged into his phpMyAdmin account.

Another incarnation of this vulnerability class was found within a form software where the admin configuration was handled by code similar to this.

   // save only modified admin options
   // BEWARE THIS CODE IS VULNERABLE
   foreach ($_REQUEST[‘options‘] as $key => $val) {
      if (isset($options[$key]) && $options[$key] != $val) {
         saveOption($key, $val);
      }
   }

In this example an attacker that is able to inject a cookie titled options[includePath] into the admin’s browser will be able to remotely include arbitrary PHP code. Because the attack relies on Delayed Cross Site Request Forgery/Hijacking the attack is even possible when the admin is not currently logged into the administrative interface. The payload sleeps and will become effective once the admin tries to change the forum configuration the next time, although there is a CSRF protection in place.

Conclusion

Once PHP 5.3 is out it is recommended for hosters to set request_order to “GP” on all the servers running arbitrary PHP applications to protect applications from this kind of Cookie DOS or Delayed Cross Site Request Forgery/Hijacking vulnerabilities.

PHP Application developers on the other hand should finally move away from using $_REQUEST for user input, because it is cleaner and more secure.

On the other hand when I visited Starbucks I had to learn the hard way that without Microsoft Windows you are an outsider in South Korea. It is simply not possible to connect to the NETSPOT hotspots within Starbucks Korea without Microsoft Windows and without Internet Explorer. On the one hand their special connectivity software only exists for Windows and on the other hand the web login seems to require an activex module for credit card payment.

With this kind of limit in place I can now understand why devices like the IPOD Touch are far cheaper in South Korea than in Germany. You simply cannot use them

I think the guys behind NETSPOT should really consider redesigning their system to be compatible to non Microsoft systems, like osx or linux. After all it is not that hard to do credit card billing.

PS.1: Yes I know that the NETSPOT hotspots seem to let everything through on port 53 UDP which might allow VPN tunnels on port 53 but I am only speaking about legal access here.

PS.2: Beside that little annoyance I really love South Korea and plan to come back as often as possible

(PDF) Lesser Known Security Problems in PHP Applications