I'm trying to obfuscate and speed up my code using Zend OpCache, but OpCache doesn't seem to have the usual functions to store bytecode in a file like other older caching systems did. As OpCache is the native method of caching files in memory in opcode, I'd like to continue using it, but I need to be able to obscure my code in the case of a system breach. (Just another security precaution)
What options do I have available to me to store my PHP files as compiled code in opcode or bytecode?
EDIT: I think people misunderstood what I was looking for for the most part. Please read my comments on the posts. I'm a professional web developer of over 12 years, so I'm not new to this. I just wanted to change my tactics a bit and see if others knew of a way to pull this off that I didn't think of.
It's definitely not a good idea to start developing your own tools for obfuscating or protecting your PHP code.
For protected your code use SourceGuardian or Nu-Coder. Both tools, however, require installing special PHP extension on server, which is not an option for many webhosting companies. These tools provide possibility to lock your code to certain machine (hardware hash, IP binding, ..), control the number of licences, expiration etc.
If you are serious about protecting your code (not only obfuscation) use virtual server + one of the tools mentioned. In run-time, both extensions hold in-memory opcached decrypted low-level code, so besides protecting the code they provide also performance boost. I tested PHP 5.5.x with loaded both SourceGuardian and opcache and there were no conflicts.
I'm currently working on developing a PHP CMF which will eventually be commercially available and I want to use traits. The problem however is that traits are a PHP 5.4 feature and apparently the popular Suhosin security patch isn't compatible with PHP 5.4.
So my question is this: is it safe to run a PHP website without the Suhosin security patch? If not, what vulnerabilities would I be leaving myself and other people using my CMF open to?
Note: I'm not concerned about shared hosting. It's expected that anyone using my CMF would have administrative control over their web server.
Suhosin was a PHP hardening patch. It did not patch any explicit security vulnerabilities -- it merely made some vulnerabilities in PHP scripts more difficult to exploit.
Some of the changes which Suhosin made were eventually rolled into PHP. For instance, Suhosin's various layers of protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error (rather than silently truncating the filename at the null byte).
PHP 5.4 is generally regarded to be reasonably safe without Suhosin involved. Going forward, so long as your application supports it, you will be better off with a newer (5.4+) version of PHP, rather than an older version with the Suhosin patch.
If you can't disable eval() (a language construct, not a function) or have a blacklist within eval to disable most of the hacker's toolbox within eval, then you are running a load of bandwidth that is irresistable to hackers looking for bandwidth to run their payloads. What to blacklist, ideally, can't always be done because 3rd party module writers or even framework core depends on some of these functions within an eval() context:
suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select
If you can't filter for these functions then a major component of security is missing.
Here are some examples of Remote Administration Tools (RATS) that will infect your site, through any vulnerable 3rd party module or site user account.
RATs can take many forms, some are easy to grep for:
<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...
<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...
Some are more professional and obfuscated, and cannot really be grepped for, and cannot be found unless suhosin tips you off that they executed:
<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...
<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>
(note in this case the CACHE directory cannot be in source control, therefore cannot be tracked either)
IMHO, the statement above from duskwuff, that things would be fine without Suhosin is neither authoritative nor necessarily correct (especially given the amount of critical holes newer PHP versions have seen since then).
To my mind, it would be definitely better - from a security POV - if Suhosin was available for current PHP version.
Of course, as it is not, staying at old (eventually unmaintained) versions of PHP isn't a solution either.
Generally PHP and especially PHP applications are notoriously known for having security issues... so the question is less "are newer PHP versions safe without Suhosin"...
PHP 5.4 finally removed safe_mode and magic quotes.
Are there any alternatives to them? To enhance the security level?
I think the point of removing these features is that the PHP development team acknowledges that implementing security features/mechanisms in the application stack is not a panacea for securing Web applications.
There shouldn't be direct code/configuration substitutes for these features in PHP. Instead:
application developers should be more explicit about such things as reading in values from requests and the environment AND validating and escaping values, instead of letting features like register_globals and magic_quotes do so indiscriminantly.
system engineers and system developers should consider permissions for all filesystem resources required by an application rather than having safe_mode limit the accessiblity and efficacy of built-in functions.
I'm sure someone will try to figure out how to re-create these features, and there will be a lot of late adopters that choose to stay on earlier versions of PHP instead of addressing security directly. But if you really are concerned about security, don't look for shortcuts.
I have been wondering about the difference between Suhosin Patch and Extension?
For example which one of them I should install with PHP 5.2.17 with Xcache 1.3.1 and Zend Optimizer 3.3.0.a?
Should it be Suhosin Extension 0.9.32.1?
Is Patch version PHP version specific Suhosin Patch 0.9.10 for PHP 5.3.4/5.3.3 and Suhosin Patch 0.9.7 in my case for PHP 5.2.17?
I also couldnt understand the clear difference between Patch and Extension from security point, how do they differ from each other?
The difference is simple. One (the extension) operates as a normal extension, so it retains compatibility with other extensions. The other (the patch) does not, so it will likely break other 3pd extensions.
Now, one thing to consider is that the patch isn't even released for the most recent versions (the latest patch version is 5.3.4, so you can't use 5.3.5 stable). Now, you could install an older version of PHP to use the patch, but that will expose you to vulnerabilities closed by the core in the latest version. Which IMHO is not worth it.
Now, I would like to make 1 thing absolutely clear. Suhosin (and the other extensions/patches and things such as mod_security) does not actually secure your code. Let me say that agian, because it's important: It does not secure your code. What it does, is closes some commonly used attack vectors, and disables some commonly abused internal functions. But it is still absolutely possible to have vulnerabilities in your code.
So, while it may help "shore up" bad code, it will not make any difference with good code. If you spend the time and energy securing your code, the patch and extension are for all practical purposes useless. But it's like a firewall in the sense that every layer is usefl as long as it doesn't get in your way too much (Especially since it's practically impossible to write 100% secure code).
Look at: http://www.hardened-php.net/suhosin/a_feature_list.html
Section Engine Protection is only available when using patched php source.
Has anybody forked PHP4 to continue support for this version?
EDIT: This isn't a question about migrating to PHP5.
As far as I know - no. PHP5 is pretty good with backwards compatibility and you should not run PHP4 on any publicly facing webserver if security is even a little bit important to you.
I would estimate that PHP5 is 99% backwards compatible. Here is a blog post with typical (small) issues you might run into, usually the way that functions behave in corner cases. Two other resources you might want to look at are Migrating from PHP 4 to PHP 5 in the PHP manual and the PHP5 Migration Appendix, particularly the backwards incompatible changes.
To sum it up: you will need to test in a detailed manner after migration. Most of the things will work, but some might fail in corner cases. Some things can be fixed by tweaking the php.ini, some need a few changes. In general, applications written for PHP4 are less secure than those written for PHP5, because some security features didn't exist or were not widely used. So something like mod_security or PHPIDS (or both) should also be considered.
There have been no known forks of PHP4 to continue its support.
PHP4's code is pretty large, and with all its extensions it would be a pretty large project to support as a legacy application.