Known Issue with some versions of Cpanel and Suhosin

[philip_clarke]

This is not a zencart bug, it is a hosting with Cpanel (and proabably WHM) issue.

Suhosin alters sessions transparently. This is not a Zencart bug, it can cause the failure of external payment gateways that need to establish contact with zencart such as linkpoint API. It has also been blamed for distorting the "Who's online" feature

ZenCart with the PHP hardening module Suhosin, unless the module is disabled Zencart behaves as if the following session functions are set.

Check SSL Session ID True
Check User Agent True
Check IP Address True

Diagnosis

The installation of suhosin can (sometimes) be checked by a phpinfo() page.

In the sessions Table in the zencart cart database, sessions appear encrypted rather like a base64_encoded variable.

examples

a normal session in the database (truncated):

securityToken|s:32:"8860ef8eae36f1bdd97a3f548fbad59a";customers_host_address|s:12:"92.22.17.169";

a suhosin session(truncated)

c2VjdXJpdHlUb2tlbnxzOjMyOiI4ODYwZWY4ZWFlMzZmMWJkZDk3YTNmNTQ4ZmJhZDU5YSI7Y3VzdG9tZXJzX2hvc3RfYWRkcmVzc3xzOjEyOiI5Mi4yMi4xNy4xNjkiOw==

Workaround, To disable Suhosin.


If Server API in phpinfo() reveals that php is running as "CGI".

Placed in the store's document root, a file php.ini

suhosin.session.encrypt = Off

and then the following lines added to .htaccess

<files php.ini>
Deny from all
</files>

If Server API in phpinfo() reveals that php is running as "Apache 2.0 Handler"

add the following lines to a .htaccess file in the store's document root.

php_value suhosin.session.encrypt Off

[devus]

Placed in the store's document root

Please explain what is meant by "the store's document root"

pardon my ignorance.

[philip_clarke]

Placed in the store's document root

Please explain what is meant by "the store's document root"

pardon my ignorance.

The folder that is the top of the webserver is called the document root, in php if you write

<?php echo "My document root is: ". $_SERVER['DOCUMENT_ROOT']; ?>

it'll print the folder name and it will be the same through the whole website no matter which folder you put the code.

So it's the first folder that the webserver sees. But it's not entirely accurate or clear above because if we put a shop on a website:

http://www.example.com/shop/

the shop's document root could be called

/SOME FOLDER NAME/shop/

and the web server's document root would be /SOME FOLDER NAME/

Basically, find the folder your shop is in and either edit the .htaccess file or create one (same goes for php.ini files)

If it goes Server 500 error when you visit the website, you've made an editing mistake.

[smallacj]

Hello. I am a sysadmin for an apache/mod_php server. A few of our customers are using Zen Cart and at least two of them were hacked and we had bots and c99shells wreaking all kinds of havoc. At first, I disabled the carts until the customer or their content provider applied your security patches.

My next step was to make sure this never happened again, so I installed the suhosin extension (the patch is already installed). This has allowed me to control php functions, including dangerous ones like exec and especially shell_exec on a per virtual host basis, as well as alert me to attempts...this has already helped tremendously in tracking down scripts and IP addresses of attackers.

Unfortunately, Zen Cart, even the patched version, doesn't work well with suhosin, which lead me to this forum and this thread in particular. I would think there has to be a better solution that completely disabling suhosin, especially as it could prevent this from happening again.

I would think that tweaking the right suhosin filtering options might do the trick. The problem is knowing which ones and roughly what values to use. Perhaps Zen developers are best qualified to answer this (see below) or if somebody already found a good set, to be kind enough to share them. Here are the options:

#
Filtering Options

*
suhosin.filter.action
*
suhosin.cookie.max_array_depth
*
suhosin.cookie.max_array_index_length
*
suhosin.cookie.max_name_length
*
suhosin.cookie.max_totalname_length
*
suhosin.cookie.max_value_length
*
suhosin.cookie.max_vars
*
suhosin.cookie.disallow_nul
*
suhosin.get.max_array_depth
*
suhosin.get.max_array_index_length
*
suhosin.get.max_name_length
*
suhosin.get.max_totalname_length
*
suhosin.get.max_value_length
*
suhosin.get.max_vars
*
suhosin.get.disallow_nul
*
suhosin.post.max_array_depth
*
suhosin.post.max_array_index_length
*
suhosin.post.max_name_length
*
suhosin.post.max_totalname_length
*
suhosin.post.max_value_length
*
suhosin.post.max_vars
*
suhosin.post.disallow_nul
*
suhosin.request.max_array_depth
*
suhosin.request.max_array_index_length
*
suhosin.request.max_totalname_length
*
suhosin.request.max_value_length
*
suhosin.request.max_vars
*
suhosin.request.max_varname_length
*
suhosin.request.disallow_nul
*
suhosin.upload.max_uploads
*
suhosin.upload.disallow_elf
*
suhosin.upload.disallow_binary
*
suhosin.upload.remove_binary
*
suhosin.upload.verification_script
*
suhosin.session.max_id_length

[DrByte]

smallacj,

simply set suhosin.session.encrypt = Off

[ecdiscounts]

This is not a zencart bug, it is a hosting with Cpanel (and proabably WHM) issue.

Suhosin is not a cPanel bug, Suhosin is a PHP harding project and can be used with any PHP install and had nothing to so with the Control Panel.

We do not use Suhosin because of all the problems that it causes.

[dimsumgurl]

Workaround, To disable Suhosin.


If Server API in phpinfo() reveals that php is running as "CGI".
[INDENT]
Placed in the store's document root, a file php.ini

suhosin.session.encrypt = Off

and then the following lines added to .htaccess

<files php.ini>
Deny from all
</files>

I tried this tip however I am still unable to view the cart...
I created a doc named php.ini and copy paste the code.

Could you provide me some tips?

Thanks

[DrByte]

It's your hosting company who has enabled suhosin, and it is also them who configured the server to allow or disallow you to turn it off. The methods posted above may not work in all situations, because every server is configured differently according to the whims of the server owners.

You need to talk to your hosting company for the correct way to disable suhosin on *your* server.