PHP Security Blog

This blog is dead

blog-admin@nopiracy.de (Stefan Esser) — Fri, 01 Aug 2008 09:16:42 +0000

This blog is finally dead.

Because the domain name limited me to blog about PHP security only I moved to the domain suspekt.org that I own for many years now. Please update all your links and feeds to point to the new URL where I will continue blogging on a regular basis.

Flash Game - 10000 of 900 possible points?!?!?

blog-admin@nopiracy.de (Stefan Esser) — Tue, 11 Dec 2007 23:05:00 +0000

A friend of mine just sent me the URL to a flash game (for obvious reasons I will not share the link) which is part of a number of games with a price of 10.000 EUR in the end. One would believe that a game with such a price money is secure. Especially when the organising party is an internet provider.

But guess what... At the end of the flash game you can optionally submit your score to the highscore server, which results in a POST to the file submithigh.php with several parameters, one parameter saying score=XXXX. And of course you can submit whatever score you want. So now I lead the highscore with 10000 of about 900 possible points. I set it that high to ensure that the guys at the ISP will realize that this is faked, but imagine I had just increased the current highscore by 10. I seriously doubt anyone would have noticed and I would have won the competition without even decompiling the flash.

Continue reading "Flash Game - 10000 of 900 possible points?!?!?"

Suhosin 0.9.21 - XSS Protection

blog-admin@nopiracy.de (Stefan Esser) — Fri, 30 Nov 2007 16:51:00 +0000

It has been a very long time since the last Suhosin extension has been released, but today this has changed with the release of Suhosin 0.9.21. Among the changes are two new features that will protect applications that put too much trust into the SERVER variables from several XSS (and SQL injection) attacks. These features are suhosin.server.strip and suhosin.server.encode.

suhosin.server.strip

When activated (which is the default) the SERVER variables PHP_SELF, PATH_INFO and PATH_TRANSLATED will be scanned for the characters < > ' " and `. All occurences will be replaced by ? characters. This stops a lot of XSS attacks, because many PHP applications consider these variables not tainted.

suhosin.server.encode

When activated (which is the default) the SERVER variables REQUEST_URI and QUERY_STRING will be scanned for the characters < > ' " and `. All these characters are usually encoded by the browser before they are sent and therefore many applications consider REQUEST_URI and QUERY_STRING safe. However some browsers like Internet Explorer will not encode these characters which results in lots of XSS vulnerabilities. Suhosin will protect applications that wrongly put too much trust into these variables by URL-encoding them within the variables.

If you have more ideas for simple features that can protect many scripts at once don't hesitate to contact us.

SektionEins @ DeepSec 2007

blog-admin@nopiracy.de (Stefan Esser) — Mon, 19 Nov 2007 08:19:14 +0000

The DeepSec 2007 conference in vienna, austria will start tommorow with 2 days of workshops followed by 2 full days of very interesting talks about different security topics. Together with my co-worker fukami I will attend the conference on behalf of SektionEins.

The speakerlist of DeepSec is very impressive, it includes Halvar Flake, Dave Aitel, David Litchfield, Martin Johns, Jeff Moss, Alexander Kornbrust and my co-worker fukami who will speak about Adobe Flash Security.

CORE GRASP - PHP Tainted Mode

blog-admin@nopiracy.de (Stefan Esser) — Wed, 22 Aug 2007 21:37:00 +0000

Core Security Technologies today announced the release of CORE GRASP, which is a patch against the PHP 5.2.3 code tree that adds a tainted mode to PHP to protect the mysql_query() function. Their implementation adds a tainted or not flag for every byte so that it is possible on invocation of mysql_query() to determine any kind of injection.

To add such a tainted mode to PHP has been discussed several times in the past. It was rejected for several reasons like the obvious huge speed impact and the danger of false positives and a false sense of security. And indeed the way CORE GRASP is implemented it looks like a huge memory and speed overhead that should be tested. In addition to that their query parser will for example wrongly detect quotes escaped by doubling as injection attack.

Aside from this there are several other possible problems in the code like a remote one byte stack overflow (that seems harmless due to memory alignment), wrong handling of the _SERVER superglobal in case of JIT and it also seems that control characters like linebreaks can be injected into the logfiles. Further analysis and a deeper look into the code is needed.

However it has to be taken into account that this is the very first public version of CORE GRASP, so maybe all these problems are gone soon and support for further database engines is added.

MOPB Exploits taken down

blog-admin@nopiracy.de (Stefan Esser) — Fri, 10 Aug 2007 16:28:00 +0000

Unfortunately I had to take down all the proof of concept exploits that were developed during the Month of PHP Bugs. The reason for this is a new law in germany that is official since today. This new law renders the creation and distribution of software illegal that could be used by someone to break into a computer system or could be used to prepare a break in. This includes port scanners like nmap, security scanners like nessus and of course proof of concept exploits.

More CSRF Redirectors

blog-admin@nopiracy.de (Stefan Esser) — Sun, 29 Jul 2007 14:15:00 +0000

Today I learned about another CSRF redirector by another group of people in web application security called GNUCITIZEN.

Similar to the previous CSRF redirector it contains the same XSS vulnerability through the javascript URI scheme.

Example:

http://www.gnucitizen.org/util/csrf?..._url=javascript:alert(/.../);

Update: The bug is fixed for now...

About the CSRF Redirector

blog-admin@nopiracy.de (Stefan Esser) — Wed, 18 Jul 2007 09:30:00 +0000

You might have seen this post in Chris blog about a CSRF redirector he did. This is basically nothing more than a little script that turns a GET request into a hidden formular that is then posted via JavaScript. There have always been security issues with redirector scripts, and if you provide one open to anyone, you should care about what kind of redirects you actually allow.

Two major risks happen to exists with chris example:

Malicious people could misuse them as bouncers to attack other sites
Not every URL is a web page. Some can load plugins, display information and
some can execute JavaScript.

Here is an example URL:

http://shiflett.org/csrf.php?csrf=javascript:alert(/I_AM_A_SECURITY_EXPERT/)

In Internet Explorer (and Safari) this will give you access to the domain (cookies, etc...). In Firefox you can still do other funny things.

So if you implement (javascript) redirector scripts, make sure you do a proper
whitelisting of the user delivered urls.

UPDATE: The above example for a simple XSS does no longer work. However there are still other XSS vulnerabilities like variable-width problems in the CSRF redirector and it is still an open bouncer for malicious persons.

BlogSecurity Interview

blog-admin@nopiracy.de (Stefan Esser) — Fri, 29 Jun 2007 18:50:00 +0000

Two days ago I was interviewed by the people of BlogSecurity about my thoughts about WordPress, their vulnerabilities and how they deal with them. The interview is meanwhile online.

What site do you want to break today?

blog-admin@nopiracy.de (Stefan Esser) — Fri, 15 Jun 2007 23:40:00 +0000

I just came back home and saw a very recent commit to PHP's session management. It is another attempt to fix the session cookie attribute injection that the PHP developers already tried to fix in PHP 5.2.3 without giving any credits. They still refuse to implement the correct fix that consists of just encoding the session id before sending it back through the cookie.

The amusing thing this time is that their new fix that consists of blacklisting a bunch of legal characters from the session id, will most probably result in hundreds or thousands of broken sites. What is even more funny is that the commit comes from a Zend employee that blacklists the ':' character from being used in the session id. The last time I audited the Zend Platform session clustering module it used exactly this character within session ids. This basically means that the session clustering of the Zend Platform will no longer work with the next PHP versions.

And as a final comment to the commiter: You are blacklisting a bunch of legal characters. Whatever RFC you used for choosing the characters for your blacklist was the wrong one. PHP implements the Netscape Cookie standard that is defined here. That document described very clearly that all characters are allowed except whitespace and semicolon. So nearly all the characters in your list are legal. Thank you for breaking lots of sites.

Chunk_split() Overflow not fixed at all...

blog-admin@nopiracy.de (Stefan Esser) — Mon, 04 Jun 2007 19:07:00 +0000

If you are one of the guys that read the PHP CVS commits you usually know about the security bugs months before the rest of the community and this is no news for you. During the last 24h the following fix was merged into the PHP CVS.

Corrected fix for CVE-2007-2872

This fixes the chunk_split() overflow (found by SEC-CONSULT) that was according to the PHP 5.2.3 release notes already fixed. The original fix was however not only broken but complete nonsense. If you can read C you will see that the integer overflow was not fixed in PHP 5.2.3 but simply moved into a separate line and an additional bogus if clause was added.

You can test this yourself with the following code:

<?php
   $a=str_repeat("A", 65537);
   $b=1;
   $c=str_repeat("A", 65537);
   chunk_split($a,$b,$c);
?>

So my recent posting that was called marketing FUD is even more true.

PS: I wonder if SEC-CONSULT was the one that reported that the fix is no fix at all or if it was one of the linux distributors. The linux distributors and their regression tests are always a good way to check if bugs are fixed correctly.

PS2: What I failed to mention in the original blog entry is that the fix of the fix is still vulnerable to an overflow, because a float number is casted to an int for the allocation. In case of big int numbers this will result in not enough memory being allocated.

Google for me and get Zend

blog-admin@nopiracy.de (Stefan Esser) — Fri, 01 Jun 2007 14:21:00 +0000

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 released...

blog-admin@nopiracy.de (Stefan Esser) — Fri, 01 Jun 2007 06:27:00 +0000

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.

PHP 4 - Reference Counter Overflow Fix

blog-admin@nopiracy.de (Stefan Esser) — Sun, 20 May 2007 15:06:00 +0000

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.

Suhosin 0.9.20 and crypt() Thread Safety Vulnerability

blog-admin@nopiracy.de (Stefan Esser) — Sat, 19 May 2007 20:35:01 +0000

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.