PHP

After updating PHP to version 5.4 (with mixed success), I am still cleaning up the fallout peu à peu. (See all entries of this mini-series here) During my holidays, the fact that my Roundcube installation is also broken bit me (I needed quick access to my flight information and the e-mail was not cached on my iPhone). Today, I tried to fix it. 

I was using Roundcube 0.8-beta with the SQLite backend, and it seemed the database was no longer accessible. SQLite is a bit picky with its permissions, so I checked that first, but the server log said: 

[Wed Aug 08 19:06:33 2012] [error] MDB2 Error: not found (-4): [Error message: extension sqlite is not compiled into PHP]\n

Whoopsydaisies, is there an extension missing? I duly checked my PHP for SQLite support and sure enough, the sqlite3 extension was loaded. But alas, Roundcube uses the outdated sqlite2 API, so it fails. I tried updating to Roundcube 0.8.0, but to no avail. After a while of googling, I found a bug in the Debian tracker that essentially said “Roundcube’s fault for using outdated code” and led to a bug in the Roundcube bug tracker (#1488332). This one was marked as fixed 6 days ago (August 08th), so I downloaded the latest nightly, marked 20120812. This nightly did not fix the issue, either.

So either there’s currently no way to use Roundcube with SQLite and PHP 5.4 or I have missed something. Does anyone have a hint for me?

(PS: The current nightly has an awesome new UI, so the update wasn’t for naught. And I have switched to MySQL for the time being.)

The PHP team has announced PHP 5.4.3 and 5.3.13, fixing two separate security issues.

• CVE-2012-2311 and CVE-2012-1823 are both fixed now. These are the CVE numbers for the PHP-CGI bug that has been announced by Eindbazen last week, and extensively covered by myself in various posts.
  


• In addition, CVE-2012-2329 has been fixed, another issue in PHP-CGI. This was a heap overflow triggered by specially crafted HTTP headers and a script executing apache_request_headers().
  

I have tested my own exploit against the new version (5.4 only, I have no 5.3 setup) and there does not seem to be a possibility to exploit the vectors opened in CVE-2012-2311 and CVE-2012-1823. These issues seem to be fixed now. I have no exploit code for CVE-2012-2329, so I cannot make a statement if it is fixed yet. Update: I have tested Georg Wicherski’s PoC exploit against 5.4.3 and it seems that CVE-2012-2329 is now also fixed.

Read the announcement here: PHP 5.4.3/5.3.13 release announcement

The download page for PHP 5.4.3 is here, the download for 5.3.13 is over here.

There is a new PHP bug that just became public today (leaked accidentially, it seems...). A flaw in the PHP CGI’s input sanitation process allows attackers to set command-line options via the query string.This behavior seems to be an oversight / misplaced design decision from 2004 and is only exploitable in specific web servers. Apache is one of them...

This opens interesting opportunities. I have blogged about those here: New Exploit @ php-security.net

By the way, Suhosin partially mitigates one of the easier remote code execution vectors that are opened through this attack. Suhosin can be circumvented completely and trivially.

(EDIT: mod_spdy seems to cause massive issues with mod_php, so I disabled it again. I am seeing lots of PHP segfaults as soon as I enable mod_spdy - these disappear as soon as it is disabled.)

This website (as long as you access it via HTTPS) is now serving pages with SPDY, Google’s still-experimental web acceleration protocol. Since SPDY mandates usage of SSL, I am using a CACert certificate to serve up pages. If you want to know why I didn’t buy a CA-signed certificate, please see this talk for a couple thoughts: SSL and the future of web authentication (PDF)

The reason this posting lands in the PHP category is that I want to have a playground testing PHP applications with mod_spdy. Currently (and probably also in the future), this machine uses mod_php instead of php_(f)cgi(d) - this is not recommended for interoperation with mod_spdy. To test the real-life impact of the possible thread safety issues, I am using my private pages as a sandbox.

 So, please test away. There is a couple of PHP applications here that might or might not work:

• A recent, PHP 5.4-patched Gallery3 installation is under https://gallery.christopher-kunz.de/


• A Wordpress installation is here: https://absynth.de/

If you have any comments, especially if you can share success stories about mod_spdy and PHP, or just want to see how SPDY performs, please comment away!

Update: You can check if you’re using SPDY already by looking into the following little page, iframed for your convenience: SPDY check

To complete the trinity of infamy: There is no Suhosin for PHP 5.4.0 either.

The patch is no longer bundled with distribution PHP. I have fired a mail to i0n1c about this but he seems to be in transit currently. The extension (0.9.33) does not compile with PHP 5.4.0 because of the copious API changes. 

Update: There is now a new version of Suhosin that is compatible with PHP 5.4.0 and 5.4.1. You can download it from Stefan Esser’s Github account (.tar.gz .zip). It compiles and runs well with PHP 5.4.0-3 (Debian Wheezy).

PHP 5.4.0-3 (cli) (built: Mar 21 2012 20:33:26)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
    with Suhosin v0.9.34-dev, Copyright (c) 2007-2012, by SektionEins GmbH

Thanks to andro for pointing this out. There is an installation howto over on php-security.net.

The “eAccelerator” project seems to be in hiatus. There haven’t been any changes to the downloadable files since 2010 (version 0.9.6.1). With PHP 5.4.0 released and a major bump in the Zend API coming with it, I was not expecting eAccelerator 0.9.6.1 to compile. And sure enough, it fails quite soon into the make process. 

eaccelerator.net is an Apache placeholder page, the SF site is not maintained anymore - time to let go.

So, no eAccelerator for PHP 5.4.0 (FWIW, anyway...) and onwards.

I recently upgraded this machine to Debian Wheezy (mainly to fix odd kernel crash issues that occured a couple times now) and this included a new PHP version. 5.4.0 has been stable for a month now, so I was eager to give it a spin. 

Almost all applications worked without any changes, apart from the popular “Gallery” script. Gallery3 just stopped working after upgrading to PHP 5.4.0. I maintain a fairly large gallery here, so it was vital for me to keep it running.

So, the TL;DR version to fix Gallery3 in Debian Wheezy with PHP 5.4.0:

• set date.timezone = <your-timezone> in php.ini and restart Apache
  


• comment-out line 530 in gallery3/system/core/Kohana.php

If you see everything twice (all pages are there twice), you have applied the wrong hotfix. Check in the bottom of the long entry for an explanation and a fix.

I will be moderator to the “WebSec Day” on the WebTech 2009 conference in Karlsruhe, Germany. The full-day workshop will consist of several, loosely thematically linked sessions regarding web security. See full entry for abstracts and speakers.


If you want to have a beer, I will only be in Karlsruhe on monday evening and tuesday during the day. You can follow me at twitter (@christopherkunz). I’m looking forward to seeing some of the PHP folks again during the few hours that I will spend in Karlsruhe.

I have recently installed SilverStripe to test if it fits into our shared hosting concept. Read after the break about my impressions.

The automatic updater for WordPress uses FTP to upload data (which is generally a good idea because of safe mode). However, it fails if the FTP account is chrooted (i.e. you cannot change to directories below your home directory).

This is bad, because most, if not all shared hosting servers have chrooted ftp accounts. There is, however, an easy fix. You just recreate the root directory structure within your home directory.

If your home directory has the physical directory “/www/12345/mydomain.com/” and your wordpress is in the “./wordpress” subdirectory, you can just log in with ftp and do this

mkdir /www; 

cd /www; 

mkdir 12345; 

cd 12345; 

mkdir mydomain.com

Then you can use a PHP one-liner to create a symlink to your wordpress subdirectory:

<?php symlink(“/wordpress”, “wordpress”); ?>

After this, you should verify the directory is created OK and can be changed into via ftp:

cd /www/12345/mydomain.com/wordpress

After this, the automatic update worked, at least for me.

I recently read about the APS project and became curious. APS, shorthand for Application Packaging Standard, is - as far as I understand it - a relatively recent standard that provides SaaS providers (i.e., us as a hosting provider) with a standardized format for software packaging. So far, some sounding names from the PHP Open Source community have embraced APS, including the notorious, but indispensable phpBB, Drupal, Magento and Typo3.
For hosters, APS is supposed to be a great addition to their portfolio:

The introduction of APS advances the web hosting industry. By implementing APS, hosting service providers can gain access to a great variety of APS applications. In turn, application vendors that implement APS, can get access to a vast sales and marketing channel via APS-enabled hosting providers.

Unfortunately, I can’t seem to find detailed documentation on the process of implementing an APS socket - the only freely available docs seem to be the standards document and ISV guidelines, both of which don’t really help me.

Now, I reach out to you PHP guys - has any of you ever had something to do with APS (preferrably on the hoster/provider side of things)? Do you have pointers as to where to start the socket implementation? I’m looking forward to your input.

It is not usually my custom to comment negatively or nitpick on other people's articles in magazines, especially not in magazines I have written for. This time however, I really must raise my voice to point out a couple of (well, actually a lot of) issues in an article about SQL injection in the current (October/November) issue of the german "PHP Magazin". I stumbled upon this when Pelle Boese of Mobile SEO fame told me about it.

As a couple of you should still remember, I wrote for that magazine until about one and a half years ago. I stopped writing for a couple of reasons. First and foremost, my shift towards Grid computing, my master's thesis and work took too much time. However, the, let's say, lean editorial process always kinda weirded me out. Mostly, manuscripts were printed as written, with no editorial changes at all. This is very trusting, but sometimes leads to fuck-ups like the one below.

I’ve been playing around with my windows mobile based smartphone in the train today and noticed that while my RoundCube installation is great for normal browsers, it sucks golf balls through garden hoses when you’re trying to access it on a mobile device.

Does anyone know about a PHP-based web mail solution that works on the tiny 320x240 display and does not use an awful lot of javascript magic?

This is mainly a note to myself and anyone who’s had this problem: If you use S9Y and have mod_rewrite rewriting active, there’s a rule saying

RewriteRule (.*\.html?) index.php?url=/$1 [L,QSA]

That means “all requests to top-level .html documents go to index.php?url=, and please append the query string!”
If you want your blog in your Google Webmaster account, you’ll have to upload an empty .html document with a Google-supplied file name to prove you are actually the domain’s owner. S9Y will rewrite that URL even if the file physically exists. You can fix this by prepending a conditional statement to the above line, so it reads like this:

RewriteCond %{REQUEST_URI} !-U
RewriteRule (.*\.html?) index.php?url=/$1 [L,QSA]

Note: This puts a tad more load on your web server due to the sub-request that is issued for each request. If you really, really have a high load on your machine, don’t use this.

I decided to put the “php-security.net” domain out of retirement and slapped a Serendipity installation onto it. The domain is meant to hold all those security articles that I want to be in English and that are somewhat too generic to put on this blog. My first article is titled “X.509 PKI login with PHP and Apache” and tackles a nice little feature that is interesting for most administrative backends. So - go check it out