The Month of PHP Security 2010 has finally begun.

During the Month of May 2010 we (SektionEins) will post every day at least one new vulnerabilities in PHP and one new vulnerability in a PHP applications. In addition to that every other day we will post an article about a PHP security topic or a new PHP security tool. Among these articles and tools are those that were submitted to us during the Month of PHP Security CFP.

BTW: You can also follow the Month of PHP Security on twitter.

This course will teach students advanced methods and techniques for PHP application audits at source code and at bytecode level. The students will get to know the most common PHP security problems and how to find them at source code and bytecode level. Throughout the course several free and open source software tools will be introduced and used in order to visualize application structure, find security problems with static and dynamic analysis on source code and bytecode level and also to break PHP bytecode encryption.

You can read the full description here. During the course students will get exclusive access to a few of our internal tools. You should apply early because seats are limited. And if you want to get training like this outside of a conference, then please contact info@sektioneins.de.

There seems to be a confusion about the accepted topics.

• We do not only accept but welcome articles about PHP security topics. The whole point of involving the community in MOPS was to gather articles about secure PHP programming or PHP security research.
• We will accept vulnerabilities in PHP applications as long the application is installed on more than 100 systems and the vulnerability gives you access to the data or to the system. However you have to write a text describing the vulnerability and what you can do with it.
• You DO NOT loose any rights by submitting something to us. You will be credited and in case of bugs you are also allowed to write your own advisory to bugtraq (or whereever else). In case of articles you can reuse them for everything you want. Only condition: no other publication before the article/bug appears during MOPS.

To revisit the full list of accepted topics: look here.

If there are no more community submissions this does not mean that the MOPS is cancelled. We at SektionEins GmbH will ensure that there is enough content to fill each day. In any case the Month of PHP Security will start on May 1, 2010.

TIP: If you send in an article please ensure that chapters titled “conclusion” actually contain a conclusion and not “WE ARE THE MOST AWESOME GUYS IN WEB APP SEC - HERE IS A LINK LIST OF OUR OTHER PROJECTS”

More and more developers have started to use Zend Framework for new PHP application development projects. This changes the way applications are developed, because more framework components are used and less core PHP functions. Therefore new guidelines for secure programming are needed.

This webinar will introduce the audience to Zend Framework features that help while developing secure applications and to features that result in security vulnerabilities if wrongly used. Zend Framework’s own security features will be explained and evaluated what kind of security problems still have to be dealt with by the programmer himself.

Because I am not entirely sure how many visitors can attend a Zend Webinar you should register early.

Immer mehr PHP-Entwickler setzen das Zend Framework bei der Programmierung neuer Applikationen ein. Für die Entwicklung bringt dies einige Veränderungen mit sich, da mehr und
mehr Framework-Komponenten benutzt werden und immer weniger direkt auf PHP Funktionen zurückgegriffen wird. Dadurch ändert sich auch der Prozess, wie sichere Applikationen zu entwickeln sind.

In diesem Webinar erfahren Sie, welche Features des Zend Frameworks die Entwicklung sicherer Applikationen erleichtern, welche Features bei falschem Einsatz zu Sicherheitsproblemen führen können, welche Sicherheitsfeatures existieren, wie man sie einsetzt und welche Sicherheitsprobleme nach wie vor alleine gelöst werden müssen.

• fixed some crashbugs for IA64 architecture
• check return value of mprotect() to ensure that memory is read only - credits: PAX Team
• fixed mprotect() call - encrypted pointer was used in revoked 0.9.9 - credits: PAX Team
• added additional hardening to destructor protection
• added pointer obfuscation to memory manager

The reasons for this rule is very simple. Without the announcement we would have to look at every new HTTP_REFERER and manually check if it is just spam, an old link to the Month of PHP Bugs, someone who just copied the blog of another person or other nonsense. In addition to that we have to find a contact address of the person who originally has written the entry and ask him/her if he/she wants to take part in the drawing. This would be too much work. Therefore announce your blog posting to drawing@php-security.org or you have no chance of winning one of the coupons.

I previously blogged about one of the new features in Suhosin Patch for PHP 5.3.x. It is now possible to adjust several internal features by setting certain environment variables on startup. This includes the memory manager canary protection, the sanitization of free memory blocks, the protection of linked lists and hashtables. When a Suhosin patched PHP starts the environment variables are evaluated and the suhosin config is written into a variable called suhosin_config.

It should be obvious that this kind of feature comes with a little problem. Certain bytes in memory now control if Suhosin’s internal memory protections are activated or not. This means that a memory corruption vulnerability in PHP could be used by an attacker to overwrite the config variable and disable the security. Because of this Suhosin Patch tries to align the suhosin_config variable to a page boundary and then set it to read only.

/* hack that needs to be fixed */
#ifndef PAGE_SIZE
#define PAGE_SIZE 4096
#endif
 
#ifdef ZEND_WIN32
__declspec(align(PAGE_SIZE))
#endif
char suhosin_config[PAGE_SIZE]
#if defined(__GNUC__)
__attribute__ ((aligned(PAGE_SIZE)))
#endif
;
 
static void suhosin_write_protect_configuration()
{
#if defined(__GNUC__)
   mprotect(suhosin_config, PAGE_SIZE, PROT_READ);
#endif
}

The implementation has some problems. First of all it only works in case of a GNU C compiler. The second and more serious problem is that it assumes that the PAGE_SIZE is smaller than or equal to 4096. Otherwise mprotect() will not correctly work. On systems where the PAGE_SIZE is bigger than 4096 the mprotect() will either fail or set too many bytes to read only. In case of a write access after the suhosin_config variable this can lead to a crash.

The Debian people saw this crash on some architectures and reacted with a patch. However they did misunderstand the security idea behind it and therefore their patch looks like this.

char *suhosin_config = NULL;
 
static void suhosin_write_protect_configuration()
{
#if defined(__GNUC__)
   mprotect(suhosin_config, sysconf(_SC_PAGESIZE), PROT_READ);
#endif
}
...
if (!suhosin_config) {
   suhosin_config = mmap(NULL, sysconf(_SC_PAGESIZE), PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
   if (suhosin_config == MAP_FAILED) {
      perror("suhosin");
      _exit(1);
   }
}

The Debian maintainers tried to fix the problem by replacing the aligned suhosin_config variable with a pointer. They then allocate a single memory mapped page and set it to read only. While this fixes the possible crash it shows that the Debian PHP maintainers did not fully understand the idea behind that code. The patch ensures that the suhosin configuration is set to read only, but now a memory corruption exploit can just overwrite the suhosin_config pointer and let it point to a memory area that contains a new configuration.

A correct fix would be to check if the dynamic page size is indeed bigger than 4096 and in this case just warn the user that he should recompile PHP with a bigger PAGE_SIZE definition and do not set the variable to read only in this case. But this might arise the next problem that the PAGE_SIZE might exceed the maximum alignment that the compiler supports.

UPDATE: I rewrote several parts of this blog entry to make it less critic and sound less aggressive. I spent the day discussing possible fixes and other problems with the current solution. The current solution is also not safe in all cases (all OS/architectures/compilers) because of intermediate pointers introduced by the compiler that are invisible at the C level. The solution to this is that the runtime configurability of Suhosin will become optional and can be selected at compile time. If the runtime configurability is selected the sysconf() method will be used to determine the correct page size. The pointer however will be protected by pointer obfuscation/encryption and maybe checksums.

The event is generously sponsored by Syscan, SektionEins and CodeScan. And the best submissions can win a number of attractive prizes. The first prize consists of 1000 EUR, a free Syscan ticket and a free CodeScan PHP License. For a full list of the submissions accepted and prizes available check out the website.

In case you are not a PHP security expert you can still help to improve the event. Spread the word about the Month of PHP Security in your blog, link to it and announce your blog posting at drawing@php-security.org and win one of ten 25 EUR amazon coupons.

The Month of PHP Security will take place in May 2010 and will be very different from all the previous “Month of Bugs” or “Week of Bugs” events. You can think of the Month of PHP Security as a conference without a conference. This means around the 1st of March we will send out a call for papers in order to collect the best advisories, the best research and the best articles about PHP security. We invite everyone from the PHP and from the security community to take part in this event.

The basic idea will be that during May we are planning to release (at least) one advisory or one research paper or one article about PHP security topics that were submitted to the public. And in the end of May our jury will select the best X submissions and give out prizes. We are still in the process of selecting good prizes and would be happy about more sponsors. Therefore: If you consider this event to be a good idea to improve the security of PHP and want to sponsor prizes, do not hesitate to contact us at info@sektioneins.de.

The accepted topics will be:

• Advisory/Article about new vulnerability in PHP (with or without exploits) (no simple safe_mode, open_basedir bypass vulnerabilities)
• Advisory/Article about vulnerability in PHP related software (popular 3rd party PHP extensions/patches, like Suhosin or Zend tools)
• Detailed article about a single topic of PHP application security
• Article about a complicated vulnerability in/attack against a widespread PHP application
• Article about a complicated topic of attacking PHP (e.g. explain how to exploit heap overflows in PHP’s heap implementation)
• Article about how to attack encrypted PHP applications
• Release of a new PHP security tools
• Other topics related to PHP (application) security

Of course we will accept multiple submissions by the same person/team and there will most probably also be articles/advisories by ourself. (But of course we cannot win the prizes)

We at SektionEins are already very excited about the event and hope it will be a success and once again improve the security of the PHP ecosystem.