Brought to you from one of the comments in my blog.

Google for "Stefan Esser" and get a sponsored link for Zend.

http://www.google.com/search?q=%22Stefan+Esser%22

Update: It seems for now their budget is gone. My name is free again.

PHP 5.2.3 was released with several security fixes.

Again not all security fixes are mentioned in the release announcement.

Again security bugs known to the developers were not correctly fixed.

More info here.

PS: Why does PHP.net always release security fixes just before the weekend?

UPDATE: Antony Dogval from Zend meanwhile wrote a blog entry where he comments on this blog entry. He claims that I did not tell the PHP developers how to fix the issue. I love it how members of the PHP development team that do not receive the mails to security@php.net try to convince the world that I never sent those mails. I wrote atleast 2 times in the conversation about the described bug that the problem is because the session id is not encoded. I am not the php.net babysitter. I repeated myself and got ignored, I am not begging PHP.net to listen to reason.

Because the PHP developers do not want to fix the PHP 4 Reference Counter Overflow Vulnerability that was disclosed during the Month of PHP Bugs the Hardened-PHP Project as usual had to step in to protect the users of PHP.

I created a patch for the refcount overflow problem that took about 30 minutes to develop and that fixes the problem without breaking binary compatibility. Something that is according to claims of Zend Engine developer and Zend employee Stanislav Malyshev not possible at the moment. You can apply it directly or wait until it was ripped and merged into the default PHP CVS after it was relabled as the work of the PHP developers.

I just released Suhosin 0.9.20 that adds a few new features and bugfixes. The most important addition is that a mutex is placed around the call to the system's crypt() function to ensure thread safety. This mutex is necessary to close a bunch of possible attacks on the libc crypt() function on multi threaded systems.

Because the libc crypt() function (and also the PHP port for windows) is not thread safe there exists a race condition that can be exploited on multi threaded systems. When for example two threads are trying to validate passwords through crypt() at the same time they are using the same internal memory area which can result in both crypt() actions returning invalid results or the result of the one operation can overwrite the result of the other. It is obvious that in this case a thread using a wrong password will return the correct crypted password if during the same time another thread calls crypt() on the correct password. In this case the application will usually login the user that used the wrong password. (However the thread race is hard to win from remote)

Because Suhosin changes the default crypt() method to the blowfish implementation it comes with, which is thread safe by default Suhosin users were safe from this vulnerability before this update, unless they provided their own salt when they called crypt().

Note: In PHP 5.2.1 the PHP developers silently closed that hole for UNIX systems that support crypt_r(). It is however very likely that they did not realise the security implications, because they have no protection for systems that do not have crypt_r(), they did not merge it to PHP 4 and they also did not fix the windows implementation.

When you read the OWASP risk evaluation standard carefully you might get as confused as I got. They estimate the risk by first estimating the likelihood and then estimating the technical and business impact. The estimation is done by assigning the numbers 0..9 to a number of factors.

So far so good. Most of it makes perfect sense, but I was a little bit confused about the following factor:

Opportunity

What resources and opportunity are required for this group of
attackers to find and exploit this vulnerability? No access or special
resources (0), limited access and resources (4), special access or
resources (7), full access or expensive resources (9)

According to this factor the likelihood of an attack increases when more access to the application and more expensive resources are required on the attacker's side. I dare to doubt that

One of the worst things in PHP security is the fact that vulnerabilities in PHP are usually patched in the CVS and then wait for months until they are disclosed to the public. Time enough for everyone to grab the fixes from CVS and develop exploits for the vulnerabilities. Therefore PHP vulnerabilities are usually already known to the bad guys for weeks or months when a new PHP version comes out and the public is notified about the vulnerability.

However sometimes even after a release the general public does not know about some vulnerabilities, because it somehow happens that they are forgotten to be mentioned in the release announcement. This happened before and has happened once again with the release of PHP 5.2.2

A while ago a bug in the mcrypt_create_iv() function was reported and fixed that caused the IV generator to create always the same IV. The bug itself is the result of calling php_rand_r() with an unitialised variable as seed. Depending on the stack layout of the system this results in the same IV being generated again and again. In some cases the stack layout might result in a totally predictable seed, which will result in a predictable IV. While this is not a completely dramatic problem, a non random IV will results in a weaker encryption. The bug is therefore a security problem that is NOT mentioned at all in the PHP 5.2.2 and PHP 4.4.7 release notes.

Oh yeah... Why the same bug in the soap extension that can be found by a simple grep for php_rand_r was not found and fixed actually beats me...

During the month of PHP bugs several people changed their credo from: "there are no vulnerabilities in PHP" to "vulnerabilities in PHP are not important, just tighten your OS". Other claimed that you can not rely on safe_mode and that you can always use shell_exec() to execute everything on the system.

It is quite amusing how the "safe_mode is flawed by design" green card is nowadays used to deny the seriousness of local PHP vulnerabilities. Just because safe_mode was a bad idea this does not automatically made disable_function a bad idea. And yes disable_function is nearly always used. Admins forbid the usage of all kind of functions like ini_get(), phpinfo(), shell_exec(), popen(), ...

So here comes the challenge. Imagine a PHP 5.2.2 server with ALL builtin functions being disabled. The challenge is to write PHP code that executes any binary inside the /bin directory. According to all those (marketing) people who claim that executing any PHP code is equal to shell access and therefore local vulnerabilities in PHP are irrelevant, this should not be too hard.

Yeah well, I guess all those not yet brainwashed by the marketing departments have already realised that without access to ALL builtin functions it requires a local PHP vulnerability to achieve this otherwise impossible task and therefore I win anyway.

Today I learned about a podcast interview of Ed Finkler one of the members of the PHP Security Consortium. I heard through the first 30 minutes and was kinda bored because it was not really about PHP Security but about educating PHP developers, which is a subtopic of PHP Application Security which itself is a subtopic of PHP Security. I already wanted to switch it off when at around 34:32 they started talking about the Month of PHP Bugs.

Well knowing that Ed Finkler is one of the PHP Security Consortium it was absolutely no suprise that his response was lacking any substance and was only colored by anti Esser propaganda. I liked his comment that I am not worth being talked about. As usual for members of the PHP Security Consortium he wants to convince the audience that I am a bad person, with the argument that I throw the principles of responsible disclosure over board.

What he fails to mention is however that half of the security bugs were released without prior notification of the PHP Security Team, because a member of the Team that also happens to work for Zend openly claimed on the PHP Internals mailinglist that he does not know about any security hole in PHP, while I had disclosed about 20 holes the 2 weeks before. When a vendor denies the existance of security holes and lies into the face of his users, he has voided all options of nice treatment.

My advice to the members of the PHP Security Consortium is: You should use the time that you waste on interviewing each other or spreading anti Esser propaganda for actually contributing to PHP (Application) Security. Everything coming from you is nothing more than hot air and pure hatred against my person.

Very recently there has been a new paper about what the authors call JavaScript Hijacking. It is about an analysis of several JavaScript frameworks for a cross domain data retrieval vulnerability through the usage of the <script> tag. The paper comes to the conclusion that in nearly all JavaScript frameworks that work with JSON encoded data, the data can be retrieved cross domain via the <script> tag.

While some might consider this news and others do not, the authors very clearly write in their paper that this kind of vulnerability is already discussed in several places. However some malicious bloggers (previous link was wrong) claim that Fortify claims to have found a new class of web-based attacks. Other bloggers, like Chris Shiflett try to disinform people that this is just a CSRF vulnerability used for information disclosure and that you cannot protect from it via the Referer HTTP header because it is spoofable by Flash.

First of all the problem Fortify describes is not bound to CSRF attacks, because it simply describes how data can be retrieved with the <SCRIPT> tag. The described problem is not the possibility to do the request, but the problem that it is possible to retrieve a cross domain answer. And because of this the statement that checking the Referer header is not a possible safeguard because it can be spoofed by for example Flash is completely bogus. It is bogus because Flash has nothing todo with <SCRIPT> tags. And even if you can perform a Flash attack with a spoofed (isn't that problem fixed in latest Flash anyway) Referer header you can still not read the response and that is what the Fortify paper is all about.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve. You will find a lot of input filters like the following one.

<?php
   $clean = array();
   if (preg_match("/^[0-9]+:[X-Z]+$/", $_GET['var'])) {
      $clean['var'] = $_GET['var'];
   }
?>

Quite common way to filter incoming data, isn't it?

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject. However the real meaning, as it is even documented in the PHP manual is that $ means the end of the subject OR not the real end but nearly, only followed by a single '\n' linebreak. This means that the following request will also pass the filter.

   http://server.tld/index.php?var=012345:XYZ%0a

In several circumstances a newline character can be dangerous. For example when you want to stop HTTP Response Splitting or Email Injection attacks. To correct the above regular expression it is necessary to add the D modifier to it that changes the meaning of the $ specifier to really mean the end of the subject. Here is the corrected example.

<?php
   $clean = array();
   if (preg_match("/^[0-9]+:[X-Z]+$/D", $_GET['var'])) {
      $clean['var'] = $_GET['var'];
   }
?>

I hope this tip helps getting rid of all these wrong filters once and for all. People using ext/filter should prepare for a recompile, too.

PS: The regular expression is now more complicated to make this post easier to understand