Dr. Christopher Kunz

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.

(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

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.

A couple weeks ago, I blogged about PHPshield’s anonymous website, raising more than an eyebrow to the ominous business practices of hiding the true owner’s identity while selling a whitelabelled product.

To my great relief, Adrian responded quickly back then, but to my dismay it seemed like he was only paying lip service. I asked him again today via private mail and his response was swift. The whois entries for phpshield.com now point to his person and we can expect additional information on the web site itself soon.
I like it when things can be resolved like that and I actually think this is a chance for his product rather than a possible competition issue.

By clearly stating what differentiates phpshield from SourceGuardian (his flagship PHP encoding product), Adrian’s company, Inovica, can create user awareness and offer a possibility to make an informed decision for the product that actually fills their needs. I’m sure he thought about something like that already and of course it’s his decision. It’s just that I would probably try to do it that way if I had two products that are not identical, but being marketed in a similar environment.

Anyway, just wanted to update you folks on this rather positive outcome. Have a nice evening. I’ll be trolling again soon

By way of a discussion in #php.de @ IRCNet, I stumbled about “phpshield.com” which offers a PHP encoding solution for a deadbeat price of 55 bucks. Other choices, like SourceGuardian, ioncube or Zend are much more pricy.

However, the phpShield.com home page did not offer the slightest clue who actually is behind that product. How someone would entrust their PHP scripts (which obviously include their intellectual property) to a product that’s not only closed-source but also sold by an anonymous third party is beyond me.

It’s common practise to whitelabel your solutions and sell them under different brands with different feature sets to different target audiences. We do this with gameservers and hosting, too. However, we always clearly state who is behind the whitelabelled solution (and we are also obliged to do this by law, which I think is good). The phpshield people do not have any clue on their pages. The domain is registered to this dude:

Administrative Contact:
Whois Privacy Protection Service, Inc.
Whois Agent (qjprnbdw@whoisprivacyprotect.com)
+1.4252740657
Fax: +1.4256960234
PMB 368, 14150 NE 20th St - F1
C/O phpshield.com
Bellevue, WA 98007
US
Hm. Their hoster, hostovo, belongs to an Inovica Ltd. in the UK. Waitaminute... inovica? Ah yes, the guys that sell SourceGuardian for over 4 times the price of PHPShield. And oddly enough, PHPShield.com’s privacy policy lists Inovica Ltd. as the sole proprietor of any IP on the page. I’m seeing a pattern here...

I really have to ask: Why are they trying to hide? To me, that is not acceptable business practice. Incidentially, I’m currently evaluationg PHP encoding solutions for a customer request and I just struck one off the list.

UPDATE: Adrian has responded in a very helpful comment, clearing a lot of the issues up. Please check the comments to this entry.

Hi,

just a real quick hotfix to the critical vulnerability described in this advisory:

<Files cmd.php>
Deny from All
</Files>

Put this into the .htaccess in your cacti directory and you should be good. This does not have any impact on the poller cronjob and does not require code or ini changes.

The Hardened-PHP Project is happy to announce another success story for Suhosin: Finally, we have the suhosin extension in Debian/Unstable. If you have the 4.0 version of Debian, you can now use the following packages to install PHP4 / PHP5 with Suhosin support:

irc:~# apt-cache search suhosin 
php4-suhosin - advanced protection module for php4
php5-suhosin - advanced protection module for php5

Great work, Debian guys!

Yesterday morning, I went to see Ben Ramsey’s talk on filtering. Although it seemed that beer-induced sleep deprivation had taken its toll on Ben, he presented his audience with a couple of valuable insights. Basically, what he conveyed to me (and his blog entry supports this) was not to use ext/filter or Zend_Filter at all. Nearly every second slide regarding functions of the ZF component or the extension contained remarks like “This doesn’t work yet, it’s a TODO”, “this won’t validate XY properly” or - particularly hilarious - “this function validates phone numbers, but they have to be US ones”. Useful. I have, like, 0 US customers.

So basically, if I was getting Ben right, we have an extension enabled by default that is of very limited use whatsoever. Is that a good thing? I dunno.

Since I’m currently planning the second edition of my book “PHP-Sicherheit” (if you’re a US or UK publisher and want to publish a localized version, do contact me!), I was contemplating the thought of adding a couple of references to ext/filter in the various input filtering chapters. After Ben’s session, I am not sure anymore.
Will ext/filter get enough developer attention over the next 4 or 5 months so it can actually become universally usable?

Does it make sense to enable unfinished extensions by default?

In the “information gathering” chapter of my book “PHP-Sicherheit” and my presentations on the same topic, I usually talk about how incredibly weird stuff can end up in the source code of rather big web sites. While checking a number of sites for a specific vulnerability, I ended up finding the following stuff. I modified it so there’s no real information leakage and am currently trying to reach the respective vendors.

<!--
<table class=“debug” width=“100%”><tr><td>
<a target=“_blank” href=“/sys/admin/”>- Zur Admin-Seite</a><br>
<a target=“_blank” href=“http://someothersite.de.de/gui/”>- Styleguide</a><br>
<a target=“_blank” href=“/sys/info.php”>- Phpinfo ()</a><br>
<br>
<a href=“http://validator.w3.org/check/referer”><img border=“0” src=“http://www.w3.org/Icons/valid-html401” alt=“Valid HTML 4.01!” title=“Valid HTML 4.01!” height=“31” width=“88”></a>
</td></tr></table>
-->

Another nice one:

<!--DB-Error in Zeile 1712: DB Error: syntax error: / Layouttyp3: - / SELECT layouttyp.datei,layouttyp.name FROM layouttyp INNER JOIN teaserplatz ON teaserplatz.layouttyp_id=layouttyp.id INNER JOIN teasertyp ON easerplatz.teasertyp_id=teasertyp.id INNER JOIN dokument ON teaserplatz.dokument_id=dokument.id WHERE teaserplatz.pos=5,’erbt_layout’ AND dokument.id=14528 AND teasertyp.name=’sonder’-->
<!--Fehler: Datei /export/www/CONTENT/soim-80/docs/cms/teasermanager/teasersnippets/ nicht gefunden<br>-->
And finally:
WARNING in file e:\Daten\enid\host\htdocs\media\layout\141.php on line 227: mysql_num_rows(): supplied argument is not a valid MySQL result resource
Although it might seem obvious, I cannot stress it enough: Remove debug code and possible PHP errors from your production sites!

I already blogged this at our PHP Security Blog, but it is not (yet? hey Toby ) aggregated on planet-php, so here goes again.

You can now download my session slides for the full-day workshop on PHP security - unfortunately for my international readers, they are in German. If that doesn’t scare you (because you got taught lots of useful german phrases in the last days, right Caitlin? ), you can get them here:PHP Sicherheit Workshop.

If you need a little explanation on the PHP Security Quiz by Mayflower, just read the extended entry.

I already blogged this at our PHP Security Blog, but it is not (yet? hey Toby ) aggregated on planet-php, so here goes again.

You can now download my session slides for the full-day workshop on PHP security - unfortunately for my international readers, they are in German. If that doesn’t scare you (because you got taught lots of useful german phrases in the last days, right Caitlin? ), you can get them here:PHP Sicherheit Workshop.

If you need a little explanation on the PHP Security Quiz by Mayflower, just read the extended entry.

18:44:03 recorda warum ist mein code scheisse?
18:44:08 @absynth weil er unsicher ist
18:44:25 recorda rennt sowieso über https

Update:



21:49:49 recorda absynth: sicherheitsscripts ist doch voll umsonst wenn ich ne .htaccess mach kann
eh niemand rein in das script ausser dem admin der das cms benutzt

(aus #php.de)

After updating MySQL to 5.0.22 (needed for some projects) on our development box and recompiling PHP 4.2.2, I ended up with the following error at make install:

PHP Fatal error:  Unable to start curl module in Unknown on line 0

It seems that this is indeed a MySQL issue and there is a PHP bug (bogused) as well as a MySQL bug report for the problem. There’s also a blog entry by Ilia that details a possible solution. Basically, MySQL saw it fit to link their binary distribution not against OpenSSL (which is probably available on near 100% of unixoid hosts out there), but YaSSL - of which I personally never even heard. Since function names seem to clash between Ya and OpenSSL, we have a nice mixup here that libcurl (which also links against OpenSSL) can’t really digest. It tries to call the YaSSL init function on startup and fails miserably.

So, have fun compiling MySQL manually (and don’t forget that --without-server switch if you only want client + library)!

Thanks to Pierre for pointing the link to Ilia’s blog out and to Ilia for the solution.

That was a weird week. I think I rarely changed locations that often, and I kinda lost track of what time zone, currency and/or event I was currently at. However, it turned out to be a very rewarding week, too.

All in all, I roughly travelled around 5600 km, which is probably quite a lot given the fact that I otherwise leave Hannover rarely. I changed timezones twice, currencies 4 times (including transit airports), and spoke at two different (un-)conferences. There were nights in school gyms, Sofia park bars, hostel dorms and for 2 nights, I even slept in my own home (tue->wed->thu).

My overall perception was that the security topic is still kinda “hot” and although most attendees (naturally, those at PHP Vikinger were more on top of things) seemed to have a firm grasp of what could go wrong with PHP applications, there is still a lack of trustworthy and well-designed solutions to the various security dilemmas. As Kris Köhntopp said on the PHP Vikinger, using stuff like mod_security, our Hardening Patch or other assorted security products is not a real solution, since there is no programmatical and wellformed approach to them. Instead of having a defined and limited outer and inner area for applications (like, an array of all possible URL entries to the application, as well as all possible output it generates), we are putting out fires as they emerge. Of course, we do that because we currently have no other way of keeping our boxes alive and the attackers out as long as possible, but still, Kris has a point.

During the WebTech 2006 conference, I had the chance to look at the rather new (May ‘06) O’Reilly book “Building Scalable Web Sites” by Yahoo’s Cal Henderson. I bought it and read thru some of the chapters in the airplane back from Sofia. Turns out it was a pretty good buy. The author clearly shows expertise in all kinds of scaling (vertically, horizontally and probably even diagonally, with your eyes closed, while being tortured by tiny little BSD devils) and outlines proper approaches as well as handy tools for the admin and developer.

There is even a lot of code in there, mostly to show where bottlenecks are, how to find them and how Flickr solved them, creating more scalable PHP code and in the long run, a more scalable web site. He points out that for the huge masses of photos they have to store, they actually invented their own storage protocol, mitigating some problems they had with FTP and SCP.

While there’s probably something in that book for every administrator and web developer, I’d like to point your attention to a very neat little CLI tool Cal presents. It’s called “Slurm” (web site or apt-get install slurm) and it basically gives you a real-time graph of your network interfaces’ current thruput. Nice for seeing what happens on a box, without having to wait for your RRDTool graphs to update. See the screenshot below.

All in all, very nice book so far and well worth the money. You should buy it.