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

We are on day 5 of the Month of PHP Bugs, meanwhile details for 11 Vulnerabilities were disclosed, including 2 Bonus vulnerabilities covering local root vulnerabilities in the Zend Platform.

The reaction has been quite positive so far. Emails we got were all positive and included a few emails by people who wanted to be part of the MOPB and sent us their 0-day PHP bugs. So far only one or two of the bugs sent in were on our list. Therefore we consider releasing them in the next weeks. Of course with full credit.

On the other hand there were some people in several forums (who of course are anonymous) that argued that this is all not as bad as it sounds and that you cannot take the vulnerabilities seriously. They argue that for example bug 1 and bug 4 would be the same bugs. Quite amusing, because they might exploit the same problem: lack of reference counter checks but are far from being the same bug. This is like considering all bufferoverflows to be the same bug, because they all exploit missing buffer boundary checks.

Other's were arguing that bug 9 cannot be counted because it only appears in the CVS version of PHP. This thinking seems to be quite typical in the PHP community. Complete disrespect for other people's work. Let's not forget that without these PHP CVS fixes that the Hardened-PHP Project did in the past, there would be atleast 3 more core remote vulnerabilities in PHP. With core remote vulnerabilities we mean remote vulnerabilities that are inside the PHP core and can be triggered regardless of the scripts installed.

Yeah and of course there is the fraction of people that continue to spread the propaganda that all this is only for publicity. Again a sign of complete disrespect for our work. These people obviously have not the slightest clue how much work it is and how many hours one has to spend to search for these vulnerabilities, write proof of concept code and report it to the vendor that in return claims security of his product is his achievement.

And for those who have missed the commit. The MOPB already "convinced" the PHP developers to add an array depth limit. A feature that Hardened-PHP/Suhosin has since 2004 and that was considered NOT WANTED by the PHP project. History repeats. One needs to make a lot of public noise about something and the PHP developers start to consider it, like my blog entry about the holes in allow_url_include that resulted in the usual attacks on the php internals mailinglist but convinced them to fix it finally. Of course now it is labeled as the achievement of the PHP developers...

Yesterday I released Suhosin 0.9.17 in response to a bug report by Ilia Alshanetsky and some crash problems with PHP 4 that were reported during the last weeks.

The problem found by Ilia is a trivial way to bypass the hard_memory_limit of Suhosin due to a bug in PHP. Suhosin unlike PHP allows the admin to set a unchangeable memory_limit for PHP scripts that is an upper limit for calls to ini_set("memory_limit", "xxx");

Unfortunately PHP contains a bug that it does not correctly handle negative memory_limits. Instead of not accepting them it silently casts them to an unsigned integer, which results in a memory_limit above 2 GB. Suhosin < 0.9.17 did not catch this bug and therefore allows bypassing the hard memory limit with a call like.

ini_set("memory_limit", "-10000");

The Hardened-PHP Project thanks Ilia for reporting this.

You might have realised it already. March 2007 has begun and so has the long awaited Month of PHP Bugs. The initiative is hosted on dedicated servers, because serendipity cannot handle the traffic. You can reach it at http://www.php-security.org

From time to time I get the question why I recommend enabling open_basedir and on the other hand call it a solution flawed by design. This is actually a good question, because the untrained PHP user might get a little bit confused about this and might believe that I change my opinion on a daily basis.

When looking at open_basedir one has to realise that it was designed to stop PHP scripts from accessing files outside the open_basedir restrictions. I have demonstrated in the past, that this is not safe and cannot be safe, because the design is unfixable flawed, due to 3rd party libraries accessing the files themself. Demonstrated here.

On the other hand one has to look at the greater picture. Security vulnerabilities will always exist and therefore the server setup has to be hardened against attacks. Suhosin merely exists because of the reality that there will always be vulnerable code. This is something many people misunderstand. They believe it is possible to fix all security holes by teaching people. This is however unrealisitc. Even the most skilled programmer can write insecure code.

Looking at it from this point of view it becomes obvious that every bit of additional protection is good. Suhosin and maybe one day PHP itself can protect you from all remote includes, but local includes are often also possible and in many situations they can be used to include code injected onto the server by some other means. Log files but also session storage files are a good example for that. On some systems the temporary filenames are also weak and therefore on those it is directly possible to include the temporary files uploaded with a POST upload, unless Suhosin is installed.

In this context open_basedir is a very powerful showstopper for include attacks. For a remote attacker it is not possible to break out of the open_basedir restrictions if he is only able to inject the name of a file to be included. Therefore the number of files he will be able to include with such a local file include vulnerability is limited. When the open_basedir is set correctly it should not be possible to include for example logfiles. The attacks becomes a lot less dangerous due to this.

There was only one known hole that allowed bypassing open_basedir/safe_mode from remote that was disclosed by the Hardened-PHP Project in 2004.

You might have heard about it from different places already. The Month for the "Month of PHP bugs" was choosen and it will be March. This means I will post every day in March information about one or more vulnerabilities within PHP.

Today PHP 5.2.1 was released which fixes some (but not all) of the bugs I will cover in the "Month of PHP bugs". Actually the release announcement already gives a list of bugs that were fixed. As usual the release announcement gives too little information about the bugs, does describe several bugs wrongly, forgets some security bugs that were fixed, downplays the seriousness of the bugs and does not give a single line of credit.

You will not find any hint anywhere that the security bugs listed were as usual reported by third parties. The release announcement as usual tries to make it look like all of the bugs where found by the PHP developers themself, who have no problem to credit themself in the Changelog for the little fixes they commited. But the original reporters that actually did the work of finding and reporting the vulnerability and that are therefore responsible for the additional security of the PHP community are not mentioned with a single line.

The later is by the way the reason why most of the security vulnerabilities in PHP are found by the "Hardened-PHP Project". There is absolutely no benefit for a security researcher to disclose vulnerabilities in PHP. Security vulnerabilities in PHP are far more worth when kept private and sold to 3rd parties. Actually if the list in the PHP 5.2.1 release announcement would be complete and woule give proper credit it would be quite obvious to everyone that nearly all vulnerabilities in the list were actually reported by the Hardened-PHP Project and are not the work of the PHP developers.

Ah and before I forget. During the "Month of PHP bugs" it will be demonstrated that the "Added internal heap protection" in PHP 5.2.1 (unlike the one within the Suhosin-Patch) does not stop the exploitability of lots of vulnerabilities at all.

There is a very funny posting at the modsecurity blog from yesterday that speaks a bit about the combination PHP and modsecurity. Basically the entry tries to excuse the fact that most of the modsecurity rules that are in use today to protect against known vulnerabilites can be bypassed easily by simple things like adding spaces infront of the variable name.

It is quite amusing that the author blames the fact that web application firewalls parse the HTTP request in a different way than the installed application/script language (and therefore always contain bypass holes by design) onto the applications and languages. He especially blames PHP because it is so userfriendly when it comes to variable names.

I can understand that Ivan tries to defend his product. But fact is all webapplications/script languages have their own rules how they parse HTTP requests. modsecurity (and most probably other commerical web application firewalls) matches some of these understandings of HTTP partially but it does not match a single language 100% and therefore it will NEVER be secure. It is not feasible to have one parser that works on all languages because there are too many differences between the HTTP parsers.

Oh yeah... And I see no reason to especially blame PHP when a simple trick exists that works with many languages and allows getting a bunch of attacks through all modsecurity rules...

For all those not reading security mailinglists. It is time to upgrade your WordPress blog (if you are among those, not using Serendipity). Today WordPress 2.0.6 was released that fixes several security vulnerabilities. Among these security fixes are two dangerous vulnerabilities reported by us.

The first vulnerability is an XSS (Cross Site Scripting) hole in WordPress's own CSRF protection. [READ MORE]

And the second vulnerability is a very interesting SQL injection. Very interesting, because it abuses charset conversion support to bypass the database escaping routines. Our demo exploit uses UTF-7. [READ MORE]

Both vulnerabilities have the potential to compromise the admin account, which in case of WordPress might allow arbitrary PHP code execution due to WordPress features.

It seems at the 23C3 Stefano Di Paola has disclosed a universal XSS vulnerability through the Adobe PDF Plugin. Due to this vulnerability it is possible to launch XSS attacks against any site having PDF files. An example is for example:

http://www.google.com/lib.../.../...5x11.pdf#s=javascript:alert(document.cookie);

The JavaScript is simply injected through a random variable appended to the URL fragment. Because of this vulnerability I strongly advise everyone to disable the use of the Adobe Acrobat PDF plugin in their browser. For firefox you can disable it within the Settings / Content / Filetypes menu. Just change the action performed for PDF, XPDF, FDF and everything else associated with the adobe acrobat plugin.

UPDATE: Just for the record. This issue has been fixed in the latest updates for the Adobe PDF Plugin.This does however not change the fact that the majority of users most probably still run vulnerable versions.

Today I added a little simple SQL Injection Detection Heuristic to the development version of the Suhosin extension that can optionally log and block SQL queries. At the moment it is possible to log and/or block mysql(i) SQL queries that contain comments, comments that are not closed, queries with UNIONs or queries with multiple SELECT statements.

While this are very trivial checks they are very powerful and effective against a large number of SQL Injection attacks. Many PHP applications never have comments in their SQL statements, therefore any embedded comment and especially unclosed /* comments could be attempts to truncate the data after the injection point. The same is true for UNION and multiple SELECT statements (in subqueries). Both features are not used in the majority of open source PHP applications because they are not needed for the tasks or because compatibility with old MySQL versions was kept for a long time. Therefore an SQL Injection attack is very likely when either one is encountered.

Future versions of Suhosin will have a learning mode that learns the structure of allowed SQL queries and will log/block all violating queries. The release of the next Suhosin version that contains the simple heuristic and some bugfixes is planned for 1st January.