PHP

I’m cleaning up my portfolio and have this domain for sale: php-freelancing.de. It’s currently on sedo (but I’m willing to make the sale off that platform) and has been around for at least 8 years.

Any takers? Drop me a line.

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

Just by accident (you should never browse your feed reader directly before going to bed), I stumbled upon an incredibly self-ironic posting in some dude’s blog. I have to ask myself: What are you guys taking? Are you seriously discussing any kind of name-dropping as an interview subject?

It’s not only irrelevant who created a programming language, it’s even a hindrance for interviewers since all that small-talk bullshit takes precious time off the actual knowledge assessment. And I’ll be damned before I let someone who happens to know how Rasmus’s mother’s cat’s brother was named get in the way of an actual developer who knows what they are doing. Then again, I’m in the lucky position not to be able (or have to, depending on your PoV) to hire “PHP developers”.

This whole discussion is just fat bullshit. What are you thinking? I couldn’t give a fat fuck about people who know names. I don’t give a shit if someone knows that a dude wrote an, erm... “magazine” about security at O’Reilly or if some dude named Lerdorf thought it’s a great idea to do some dynamic web stuff. I want to know if people know their trade.

Really. It’s unbelievably ridiculous. Get a hold of yourselves. Are you really thinking that knowing names is worth ANYTHING?

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.

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)

For about 4 hours now, the PHP Vikinger is in full swing. Everyone arrived between 10 and 11, and together we hacked up a makeshift agenda. Remember that this is an “unconference”, so attendees are in full charge of the whole event. Our lead viking Zak, inspired by the mighty power of Thor himself, took it upon him to moderate the scheduling and get everything started. Now, everyone who wants gets up and does a presentation, starts a discussion or - as Kris is currently doing - stipulates brainstorming with the attending core developers and other PHP nerds.

The current discussion is even somewhat strategic, pointing things out that PHP still lacks, things that need to adopt to changes in our environment and stuff that is really good in comparison to other languages. Kris is creating a list of everything that’s thrown at him and every item so far has been diligently discussed.

After that, Ilia and me will do some security stuff, with him doing introductions and me likely focusing on the server side. My obsession with securing servers without touching apps is well-known, plus it’s a good place to show off the Hardening patch.

Für alle, die schon darauf gewartet haben: Peters und mein Buch, “PHP-Sicherheit”, ist endlich da! Ihr könnt das Werk, auf das wir im Übrigen ziemlich stolz sind, bei Amazon und direkt beim Verlag bestellen. Für die unvermeidlichen Errata gibts eine eigene Website: PHP-Sicherheit.de.

For everyone who’s been waiting for it: Peter’s and my book, “PHP-Sicherheit” (in german only) is finally available. You can order the book - of which we’re very proud - via amazon.de or directly from the publisher. There’s going to be an errata/updates web site under PHP-Sicherheit.de.

I am going to speak on the PHP Conference UK which will be held at South Bank University, London, UK on February 10th, 2006. Yes guys, that’s in less than three weeks

php.net has the following to say about the event: “Not bad for 50 quid”, and I think that’s kinda true. Amongst others, book author Harry Fuecks and Derick “the ez photographer” Rethans will be speaking, so register now! The conference will be the first of its kind in the UK and anyone who’s interested in PHP should seriously consider joining us for the 10th. You should, however, expedite your decision - Early Bird Discounts are only on offer until February 3rd.

My talk will focus on the Hardening-Patch for PHP, outlining the usual stuff (obtaining it, installing it, configuring it) as well as some real-life demos of what it does and how the patch has influenced the mainline PHP distributions. I will also be available for signing CACert accounts and general networking.

And, to top it off, I’ll spend a few more days in London to visit all museums and places I didn’t get around to during my stay over New Year’s.

Well, it wasn’t totally unexpected, I guess. The recently discovered remote code execution hole in Mambo has spawned a nifty little worm, called “Elxbot”. I actually referred to the (then still fairly unknown) vulnerability and to the possibility that it might be abused by worm writers in my talk at the last PHP Conference. There is a number of reasons this had to happen:

1. Trivial exploit, just like XMLRPC et al.

2. Victims easily obtainable via automated Google (either “inurl:option=com_” or just “powered by Mambo”)

3. very large install base

I am already expecting a similar outbreak for the PHPKIT holes I recently reported. It has all of the features that I outlined above, although the install base is probably somewhat limited to german users (and there, mainly to gaming clans). Seeing this, I didn’t actually publish a PoC for the remote code execution hole, but it is somewhat trivial to find and exploit anyway. So, Counter-Strike players, prepare for a bomb that is placed on your website soon, and please patch your PHPKIT installation.

At least, phpkit.de seems not to be vulnerable, although I NEVER had any official vendor response. Way to go, folks.

A rather interesting, but kinda short thread on Full-Disclosure raises a question: Why does Apache parse .php.{bak|cpp|java|many others}? I don’t see a module in Apache that could be responsible for this kind of behavior, and I can reproduce it on my local Apache 1.3/PHP 4.4.1 installation. 

Does anyone have ideas about this?

We have been running mod_php on our customer hosting servers for several reasons, but I have never been truly satisfied with that situation. The security risks are the most obvious problem, since Safe Mode is not a practicable solution and open_basedir is not quite secure enough for mission-critical applications.
Now I need to assess (err... not asses.) the breakage potential - I hope you can help me with that.

I apologize to my english readers, this announcement is probably not that interesting for you. It’s about a workshop I’m going to hold in Essen, Germany about my favorite topic: PHP security.

Für alle, die sich für das Thema “PHP-Sicherheit” interessieren, gibt es vom 23. - 27. Januar 2006 ein Intensivseminar zu PHP - Sicherheit in Webapplikationen in der “Villa Vogelsang”, auch als “Linuxhotel” bekannt. Dieses Seminar werde ich zusammen mit meinem Kollegen Peter Prochaska aus dem Hardened-PHP Project leiten.

Mehr Infos im erweiterten Eintrag.

PHP has a permissive session system. This has been decided way before I came into the PHP world (I guess in preparation of 4.0), and the reasons for this decision are kinda lost in transit. However, with a small patch by Hardened-PHP Project buddy Stefan esser, this might now change.

A small patch against PHP’s ext/session and ext/sqlite adds two new handler functions to validate and create session IDs, as well as the php.ini setting

session.use_strict_mode = 0/1

although under normal circumstances, a strict session mode handler will not bring extremely more security, it will put an end to session fixation (supplying a session ID and have it validated by PHP), some SQL injection issues (if, for tracking purposes, you store each session ID in a database) and some XSS that might arise from providing a session ID including HTML/JS code.

You can check out the patch at

http://www.suspekt.org/session_strict_mode.patch

It will also be part of the next release of the Hardening Patch for PHP.

                       Hardened PHP Project
                        www.hardened-php.net

                      -= Security  Advisory =-


     Advisory: Multiple vulnerabilities in phpSysInfo 
 Release Date: 2005/11/13
Last Modified: 2005/11/12 
       Author: Christopher Kunz <christopher.kunz@hardened-php.net>
  Application: phpSysInfo 2.4 and prior 
     Severity: Cross-Site Scripting, HTTP Response Splitting,
               Arbitrary local file inclusion
         Risk: Medium 
Vendor Status: Vendor has released an updated version. 
   References: http://www.hardened-php.net/advisory_212005.81.html

The latest PHP worm (lupii) attacks systems that are vulnerable to a remote code execution hole in PEAR::XMLRPC (or phpxmlrpc). It can only propagate on systems whose administrators have neglected to update PHP (or PEAR) in the last 3 months. Those three months have seen 4 PHP version bumps alone in the PHP4 tree, and anyone who hasn’t brought his PHP up to scale is probably a moron anyway.

However, at least for PEAR, this might be easily fixable. What if the PEAR project would introduce a flag for packets, say, “-security” and modify the PEAR installer accordingly. That flag should only be used for pure security fixes, without feature or BC breakage, so that it won’t break anything at all (apart from the exploits).

A new action for the installer, say, “pear upgrade-security” could then be introduced. It would enable admins to run pear in a nightly cronjob, only fetching security fixes and installing them in a fully automated way.

Comments, everyone - is that feasible? Does a similar concept already exist?