A few days ago one of our users requested that I look into some security features requested 2 years ago on bugs.php.net by Peter Brodersen. The first one is an addition to the session extension that stops attempts to access the session data of another user during SAFE MODE and the second one is a change in the behaviour of glob() to better obey SAFE MODE and open_basedir restrictions. In plain PHP glob() allows retrieving a list of all files on the server through the SAFE MODE or open_basedir error messages.

While I consider SAFE MODE and open_basedir broken solutions that should get replaced by proper UNIX file permissions I created two patches for both problems to make the users happy. The first problem is solved by appending the UID of the script to the session filename during safe_mode and the second one by performing silent safe_mode/open_basedir check for every single file. I did not bother commiting the patches into the PHP CVS because the bug was rejected several times as bogus.

glob_safe_mode_open_basedir_fix

session_safe_mode_postfix

I wanted to announce that in 2007 the Hardened-PHP Project is going to create a few new security products. One will be a userspace PHP Input Filtering library that can be used in PHP 4 and PHP 5 for Input Filtering in a compatible way and that is not part of some framework, so that it can be easily used in your existing application. If you are interested in contributing don't hesitate to contact us by email.

From time to time the ext/filter topic comes up. Yesterday one of its authors was attacking serendipity for having code inside that bypasses ext/filter to get the original RAW values. Quite amusing how he claims the only correct way to do input filtering is to use the ext/filter functions and only use your own functions as a fallback. Infact the only sane way is the other way around: Have your own input filtering functions and do not even think about using ext/filter. There was actually never a need for ext/filter because everything it does can be implemented on a PHP level with plain PHP functions. ext/filter is just a new irritating API to already existing functionality, that potentially introduces new security holes, because it reimplements existing stuff again.

ext/filter is a similar stupid idea like magic_quotes_gpc. When you use it, the security of your application depends on the server configuration and no longer on your application code. And if you have similar input filtering functions to be compatible with servers that do not have ext/filter (which is the majority of all servers) then there is no reason at all to use ext/filter. Supporting ext/filter makes your code more complex and in case of a bug in ext/filter you have no chance to protect your users, because security only relies on the admin's will to upgrade. Considering the fact, that ext/filter is a builtin extension this means he has to recompile PHP.

Additionally ext/filter will keep a copy of all GPC variables in memory even when it is not used, therefore it is wise to add --disable-filter to your configure line if you do not want to waste ressources.

I was quite amused today when I saw a commit to the Zend Engine by Dmitry Stogov. With this commit PHP now has a safe unlink protection, a technique originally created by me for the glibc heap implementation in 2003, that was also ripped by Microsoft for XP-SP2. Basically the whole commit is a rip-off of a memory manager protection similiar to the one in Suhosin. A protection that was always considered a no-no for vanilla PHP while I was among the PHP Security Response Team.

Yeah, well you do not need to be Harry Potter to guess what Zend is trying to do with this commit and why it is commited now. Fact is, that the people behind this patch have obviously not a security background and therefore it is not a suprise that the implementation violates several DONOTS that exist for heap protections. It is less secure than the one in Suhosin and therefore it is quite likely that I will have to completely remove the code from this commit in future versions of our patch.

Actually one question remains. How does a safe_unlink and canary protection fit into the "PHP is secure" propaganda?

Within a shared hosting environment it is sometimes quite often possible to bind yourself to some high TCP port and accept incoming connections. Sometimes this is possible because you also get a shell account on the box and sometimes because dangerous PHP functions like stream_socket_server() are not disabled in the configuration. Unfortunately the ability to bind yourself to a port and receive connections is a threat to webapplications installed on different virtual hosts on the same IP, even if other security measures in place, like tight filesystem permissions or executing PHP script with the permission of the owner.

Consider the following PHP script, that will accept incoming connections on port 7778 and print out the connecting user's IP and the content he sends until an empty line.

<?php
  $socket = stream_socket_server("tcp://0.0.0.0:7778", 
                                   $errno, $errstr);
  if (!$socket) {
    echo "$errstr ($errno)<br />\n";
  } else {
    while ($conn = stream_socket_accept($socket)) {
      echo "<h3>".stream_socket_get_name($conn, true)
               ."</h3><br />\n";
      do {
        $line = fgets($conn);
        echo $line . "<br />\n";
        ob_flush(); flush();
      } while (!feof($conn) && strlen(trim($line))>0);
      fclose($conn);
    }
    fclose($socket);
  }?>

Now guess what happens when you connect with your browser to http://my.bookshop.shop:7778/ which happens to share the same IP with your script. The browser will connect to the port under your control and send it's HTTP headers to your script. Unfortunately this HTTP headers will also contain the cookie stored for http://my.bookshop.shop/ because browsers do not save the port number of the HTTP server that orginally set the cookie. This enables anyone on the same IP with the ability to accept connections to steal cookies from other people's webapplications.

A trivial but annoying trick. And considering how many people are vulnerable to URL Include vulnerabilities you can be pretty sure that the majority of PHP5 hosting servers will allow stream_socket_server().

Last night I finally retired from the PHP Security Response Team, that was initially my idea a few years ago.

The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin.

For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.

When you report an XSS security problem in a web 2.0 site you usually assume it will get fixed as soon as possible. Obviously the guys at del.icio.us think different...

From time to time I visit the Diary of the internet storm center. Sometimes they write very interesting stuff and sometimes plain nonsense like repeating again and again the urban legend that allow_url_fopen protects against URL include vulnerabilities.

Today there was once again a very amusing post from Tom Liston from Intelguardians. The post is about a piece of encoded JavaScript malware(?) that was found on a site and the process of decoding it. While it is true that the encoding used in this case was not very smart the amusing part of this post is that it is a rant against JavaScript and JavaScript programmers. While he is at it he calls JavaScript a toy language and JavaScript programmers: wanna be real programmers.

When you read this you think that this guy has most probably never seen the amount of JavaScript behind large Web 2.0 sites or never seen the power of Firefox extensions that are completely written in JavaScript. You start thinking about him beeing an Internet Explorer user, which is kinda strange because most security professionals choose one of the real browsers like Firefox, Safari or Opera. Which does not mean that they are more secure but the amount of Firefox plugins for header/request manipulation alone, are reason enough for many professionals to use it for their daily work. And extensions like NoScript simply do not exist for IE. (Or am I wrong?)

So far the Firefox advertisement, back to the JavaScript malware. Tom continues to rant about the malware author beeing not so clever, because he used array notation to access the content of strings, which does not work according to Tom.

Turns out, it was the JavaScript jockey who wasn't so clever. Dude...
if you're out there and reading this, take some notes, ok? You can't
access a string using array notation: "a[c]" doesn't work. Here's how
you fix it: you need to replace "a[c]" with "a.substr(c, 1)"

At this point you have to smile. Lesson one you learn when working in web application security is that just because something does not work in your browser, this doesn't mean it will fail in another browser, too. Tom's observation is most probably correct, because you cannot access strings using array notation in this toy browser called Internet Explorer, but in browsers like Firefox or Opera this works perfectly.

It is actually not the first time that Suhosin caught a possible remote code execution vulnerability, but this time it is documented in the public. Yesterday a friend asked me why the uploadprogressmeter extension does not work together with Suhosin. After a while he realised that instead of failing silently he had ALERTs like this in his error log (when you look into the blog of the author you will see that others had similiar problems).

ALERT - canary mismatch on efree() - heap overflow detected

When you see such a message this usually means that some component has done something terribly wrong. Sometimes without Suhosin you would see nothing at all or mysterious crashes, that might only happen under some circumstances because of the memory layout. But in many cases such problems can be used for (remote) code execution exploits. Especially in PHP 5.2 because the new Zend Memory Manager makes exploiting HEAP overflows easier and more stable than the old one. (In previous PHP versions there was the chance that overflows were detected by the system malloc() function, which is due to the new memory manager no longer possible.)

Back to the fileupload extension. I downloaded it and looked into the code (that is luckily short) and indeed it contained a possible remote code execution vulnerability that can be abused by malicious POST fileupload requests.

Suhosin did not only stop this possible code execution exploit but helped ordinary users to detect it in the first place. Once again a dangerous and unknown vulnerability was killed once and for all by the simple use of Suhosin-Patch.

A few days ago I blogged about the anti open source features of ionCube loader that were not tricked by the simple stealth loading tricks Suhosin uses to load together with Zend products. Because of this the stealth loading of the Suhosin extension was changed to be even more stealthy.

I really dislike the fact that this is necessary, because the more stealth features one has to implement the higher is the probability that there is a compatibility problem. Therefore it is now possible from within php.ini to completely disable stealth mode. In case you are not running untrustworthy closed source binary extensions that backdoor PHP like ionCube loader you can simply disable it.

BTW: It is quite possible that the ionCube guys will start a cat and mouse game and will try to detect Suhosin and refuse to work. Just tell me about it and I will work around this again. If it were up to me I would simply commit code to the Zend Engine that stops ionCube products from loading within a vanilla PHP to show them what the open source world thinks about their untrustworthy Zend Extension backdoors.