Suhosin 0.9.16 with Stealth Mode

Sunday, December 3. 2006

A few days ago I blogged about the anti open source features of ionCube loader that were not tricked by the simple stealth loading tricks Suhosin uses to load together with Zend products. Because of this the stealth loading of the Suhosin extension was changed to be even more stealthy.

I really dislike the fact that this is necessary, because the more stealth features one has to implement the higher is the probability that there is a compatibility problem. Therefore it is now possible from within php.ini to completely disable stealth mode. In case you are not running untrustworthy closed source binary extensions that backdoor PHP like ionCube loader you can simply disable it.

BTW: It is quite possible that the ionCube guys will start a cat and mouse game and will try to detect Suhosin and refuse to work. Just tell me about it and I will work around this again. If it were up to me I would simply commit code to the Zend Engine that stops ionCube products from loading within a vanilla PHP to show them what the open source world thinks about their untrustworthy Zend Extension backdoors.

Posted by Stefan Esser in PHP, Security at 13:34

Comments (8)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Stanislav Malyshev ()

Using the word "backdoor" to describe something entirely different is BS. You work with security, so you should know what the words mean. And you were explained number of times that there's nothing "anti open source" in it, there are reasons for it entirely unrelated to open-sourcseness, which you can agree or disagree with, but represent it as it is anti-opensource after it was explained to you - it is just pure disinformation.
I guess it is very good that it's not up to you to mess the PHP engine just "to show them".

posted on Monday, December 4. 2006

#2 Stefan Esser wrote (Link) ()

Sorry Stas,

first of all http://www.ioncube.com/untrusted_extensions.php clearly admits that it is an anti open source feature.

Secondly: a backdoor is a piece left in a program that gives the programmer control over the system that has nothing todo with the original functionality of the program.

In case of Zend Tools, this additional control is enforcing YOUR whitelist of extensions. This control feature has nothing todo with the original functionality of the software and therefore is a backdoor. And the word is used wisely. And infact I don't care what reason Zend has to implement this feature, it has nothing todo with the functionality of the Zend Products and enforces restrictions on the user he must be made aware of before buying your stuff.

If PHP development was up to me a lot of things would be different. Less marketing nonsene, more quality control and more security.

PS: And yes of course. Products like Zend Guard are not anti open source...

posted on Monday, December 4. 2006

#3 Stanislav Malyshev ()

http://en.wikipedia.org/wiki/Backdoor

A backdoor in a computer system (or cryptosystem or algorithm) is a method of bypassing normal authentication or securing remote access to a computer, while attempting to remain hidden from casual inspection.

http://catb.org/esr/jargon/html/B/back-door.html

[common] A hole in the security of a system deliberately left in place by designers or maintainers.

posted on Monday, December 4. 2006

#3.1 Stefan Esser wrote (Link) ()

Will you be happy when I change backdoor into Trojan Horse?

Maybe it is the better choice of words...

posted on Monday, December 4. 2006

#3.1.1 Stanislav Malyshev ()

My opinion is that by abusing technical terms in order to make things you don't like sound worse that they in fact are, you undermine your own credibility.

posted on Saturday, December 9. 2006

#3.1.1.1 Stefan Esser wrote (Link) ()

Stanislav,

I don't know if the Zend Guard/Zend Optimizer documentation says a word about this compatibility feature. But If I were you I would add a fat warning sign about the artificial incompatibility with 3rd party extensions introduced in your products.

Zend Guard customers could otherwise sue Zend for their losses, because their encoded products are not useable by their customers as soon those want to use 3rd party zend extensions. This are hidden "defects" in your product you know about but refuse to fix (and most probably refuse to document).

I guess the only reason this has not happened yet is that there are not many Zend Extensions around.

posted on Sunday, December 10. 2006

#4 ionCube ()

Unfortunately the author is mistaken on this issue, and as is clear to everyone who knows the products or who would ask us about such things, there is certainly no conspiracy against opensource code.

Going back several years, an optional feature of our encoding tools was that encoded files could be prevented from running if unrecognised, or "untrusted" extensions were installed. This was purely well intentioned, and whilst there were always potential workarounds given that PHP itself is opensource, the feature effectively prevented someone trivially taking an existing extension as a starting point and making some changes with the intention of trying to use the modified extension to compromise the runtime system in a way that would be undesirable. In the early days this feature was enabled by default but could be disabled when encoding.

After a while we recognised that some Encoder users did not realise that this feature even existed as they had not read that far in the User Guide, and in our product review process, we decided that the behaviour should be changed so as to be disabled by default and explicitly enabled if the Encoder user chose to do so. This would ensure that a user was aware of the feature, that it might restrict where code would run, and that it was their choice. This change was at least a couple of years ago, and is a non-issue for pretty much everyone now.

On the subject of compatibility, actively creating incompatibilities makes no sense to us as it is entirely counterproductive and working against the best interests of everyone. In our business we commit to support not only the users of our Encoding tools, but also the end users of encoded files and the hosting providers who for the most part wish to offer support for encoded files to their end users. Part of that support is doing the best that we can to ensure that components are as compatible as possible so that end users are not required to make a compromise on their system. With countless servers on the internet making use of the latest OpenSource EAccelerator for performance enhancement plus the ionCube Loader and Zend Optimiser, and there is clearly no conspiracy against OpenSource extensions.

posted on Thursday, January 4. 2007

#4.1 Stefan Esser wrote (Link) ()

Please spare us your FUD.

The ionCube Encoder alone is an anti open source product.
The "argument" that a Zend Extension could influence the actions of the PHP engine in an easy way is nothing more than FUD, because it is even easier to directly modify the PHP source code.

In your product documentation you call Open Source extensions "untrusted" and you only consider "closed source" extensions by companies trusted. You can tell your grandma that statements like this are not anti open source. No one here will eat your propaganda.

posted on Thursday, January 4. 2007

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