Trusted Zend Extensions

Thursday, November 30. 2006

Everyone that has used IonCube or Zend tools has most probably experienced the problem that both companies ship extensions that backdoor PHP in a way that only those extensions can be used that they consider trusted. On pages like this they claim this is another (optional) security feature. In reality it does not offer any additional security, because everyone who is able to install Zend Extensions on a server is also able to directly patch the untrusted code into the PHP installation.

The most likely real reason for these backdoors is to keep Open Source alternatives to their products away from the PHP installation.

Because of this the Suhosin extension already contains stealth loading features that are able to bypass the Zend checks. Unfortunately until today I was not aware that IonCube comes with a similiar protection that is only activated if the encoded files request it. Of course future Suhosin versions will work their way around this backdoor.

However I decided to take further actions against this kind of anti-open-source actions and will create a patch against the PHP codebase (that will also be added to Suhosin-Patch) that will introduce the concept of extension trust. The basic idea behind this feature is that the admin can give different trustlevels to extensions, so that an extension can only see those of a lower trustlevel. Additionally it will not be possible for an extension to learn it's own trust level so that the encoder backdoors cannot demand to have the highest trustlevel.

From my point of view it is really sad, that companies with a business model based on extensions and support for open source take such drastic steps against open source products.

Posted by Stefan Esser in Security, PHP at 14:58

Comments (6)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Ilia Alshanetsky wrote (Link) ()

What a load of crap on the IonCube site:

"Engine Extensions can control the behaviour of PHP at runtime and are therefore very powerful. Because of this, ionCube considers only ClosedSource extensions written by established companies to be "trusted"."

On the bright side as soon as you close source your extension you're half way there to being "trusted". I wonder if it applies if you distribute binaries

posted on Thursday, November 30. 2006

#2 Stefan wrote (Link) ()

That comment on the IonCube site (quoted by Ilia) is the complete opposite of the real situation. I'd fully trust an open source extension because I'd be able to check what the code is doing, however with closed source you can just hope that it only does what the manufacturer says it does... you can not check if it does not do anything else that might actually bring harm. Of course the fact that these companies are established companies, if they'd do something stupid and it would be somehow exposed, they'd be dead... but still, you never know what they are doing if it's closed source. So the comment is indeed huge bullsh*t.

posted on Thursday, November 30. 2006

#3 Richard Thomas wrote (Link) ()

By trying to control how there module runs they may be trying to sidestep issues with modules that hook into the zend engine and basically allow people to side step there module to get a "uncompiled" version of a ioncube encoded file

So while I see a possible reason behind there thinking, its flawed thinking, poorly worded and provides them very little protection at all.

They might as well use a paintball condom on a 9mm pistol.

Even if thats not why, they are basically pissing on the open source community that there product needs to be viable.

posted on Thursday, November 30. 2006

#4 Zeev ()

Stefan,

First, your use of the word 'backdoor' is simply wrong in my humble opinion. The word backdoor has nothing to do with what these extensions are doing - preventing potentially incompatible extensions from loading. Backdoor is a word with security connotations, so I'd appreciate it if you changed the text to reflect the fact that they 'change the behavior' or 'patch' or whatever. It's definitely not backdoor.

Secondly, the reason we (Zend) does this is to ensure compatibility. Most of the engine extensions out there are incompatible with Zend products, because they change the behavior of PHP in a way that can potentially prevent some of the hacks that we do in our products from working. I can't speak for ionCube, but as far as Zend's concerned, it's definitely not an issue of security - it's an issue of compatibility and support.

If you want to make Suhosin load in stealth mode that's entirely up to you, but it does mean that it may cause incompatible Zend extensions that make certain assumptions to crash or misbehave. I can tell you that we at Zend are now considering whether we would like to officially support systems that have Suhosin installed on them. If & when that happens, it would mean that we test our products with Suhosin installed to ensure that there are no incompatibilities or bugs in either product that trigger unwanted symptoms when they meet each other.

posted on Thursday, November 30. 2006

#4.1 Stefan Esser wrote (Link) ()

Zeev,

I don't care how you call it. Refusing to load when unknown Zend Extensions are present is an anti open source feature.

It would always be possible to just spit out a large warning banner into error log like: We don't like open source extensions. We don't give you support if you use open source extensions.

I think then noone would actually care about this. However: simply refusing to load and to enforce admins to uninstall 3rd party extensions that are unknown or unwanted by you is ... (CENSORED) ...

Or just add a php.ini switch: zend.disable_our_anti_opensource_features=On

posted on Sunday, December 3. 2006

#5 Kurt Radwanski ()

Excellent. I full support you 100% on the trusted extension patch. It's low and evil that an extension would incorporate features that explicitly break open source ideology just so that they can earn an extra buck by butting out arguably better open source alternatives using scare tactics.

Best of wishes in your endeavours. =)

posted on Friday, December 29. 2006

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar