In line 242: gettimeofday(&tv, NULL);

gettimeofday is used. It should be included from time.h

Patch:
http://pastebin.com/raw.php?i=BknYmhFd

I’ve included suhosin extension into DirectAdmin package management tool. However, there seems to be a bug in suhosin extension. I’m running PHP as PHP-FPM, if there is no script at all it still thinks the file does exist and shows:
May 8 13:56:06 testing suhosin[31355]: ALERT - fileupload verification script disallows file - file dropped (attacker 'xx.62.57.xx', file '/var/www/html/roundcube/index.php’)

While the error should be:
unable to execute fileupload verification script /path/to/the/script - file dropped

If I use a correct path to the upload verification script (it’s chmod +x) and just does:

!/bin/sh

echo 1;
exit;

[root@testing custombuild]# ls -l /usr/local/php56/bin/php_uploadscan.sh
-rwx--x--x 1 root root 116 May 8 14:04 /usr/local/php56/bin/php_uploadscan.sh

It does still show:
May 8 13:56:06 testing suhosin[31355]: ALERT - fileupload verification script disallows file - file dropped (attacker 'xx.62.57.xxx', file '/var/www/html/roundcube/index.php’)

If I chmod it to 755 (+r), then the script works fine… So I think there should be a check if suhosin is able to execute the script, and if not - do not use it at all (do not drop files).

Also, I think it would be great to include the script name to the following alert:
"fileupload verification script disallows file - file dropped”

Thank you!

On http://www.hardened-php.net/suhosin/how_to_install_or_upgrade.html , the ./configure instruction to compile the extension into PHP 5.3.10 does not work:

http://www.hardened-php.net/suhosin/how_to_install_or_upgrade.html says:

> [./buildconf - in case you want to compile suhosin statically]

> ./configure --with-whatever-you-want [--enable-suhosin]

> make

> make test

> make install

I downloaded http://download.suhosin.org/suhosin-0.9.33.tgz
untared to directory /php-5.3.10/ext/suhosin

php-5.3.10 # ./configure --prefix=/usr --datadir=/usr/share/php --mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-libdir=lib64 --with-config-file-path=/etc --with-exec-dir=/usr/lib64/php/bin --with-apxs2=/usr/sbin/apxs2-prefork --with-openssl --with-bz2 --with-zlib --with-curl --with-ldap --with-mysql --with-mysqli=mysqlnd --enable-soap --enable-mbstring --with-xsl --enable-calendar --with-gd --with-iconv --with-pspell --with-gmp --with-mcrypt --enable-zip --enable-bcmath --enable-suhosin
and got at the end

Notice: Following unknown configure options were used:

--enable-suhosin

Check './configure --help' for available options

Please can you advise, or correct the text on http://www.hardened-php.net/suhosin/how_to_install_or_upgrade.html ?

Need more testcases.

At least one testcase by feature...

The extension won't compile with PHP 5.4:

/stefanesser-suhosin-13620d2/suhosin.c: In function ‘suhosin_register_cookie_variable’:
/stefanesser-suhosin-13620d2/suhosin.c:652: error: ‘struct _php_core_globals’ has no member named ‘magic_quotes_gpc’
/stefanesser-suhosin-13620d2/suhosin.c:689: error: ‘struct _php_core_globals’ has no member named ‘magic_quotes_gpc’
/stefanesser-suhosin-13620d2/suhosin.c: In function ‘suhosin_register_cookie_variable_safe’:
/stefanesser-suhosin-13620d2/suhosin.c:720: error: ‘struct _php_core_globals’ has no member named ‘magic_quotes_gpc’

Post handlers are not replaced when Apache SAPI is used. I think this must be due module start order being Zend > Modules > SAPI (unconfirmed).

The fix for this problem is to change the hooking position to the activate stage (that is run after the startup stage).

I have done this patch and confirm ELF uploads are successfully intercepted and dropped in both Apache SAPI and CGI SAPI (the latter does work, even without this patch).

diff -uNra suhosin-0.9.36/suhosin.c suhosin-0.9.36.new/suhosin.c
--- suhosin-0.9.36/suhosin.c    Tue Jun 10 09:58:36 2014
+++ suhosin-0.9.36.new/suhosin.c    Wed Aug 13 18:14:07 2014
@@ -46,18 +46,19 @@
 static int (*old_startup)(zend_extension *extension) = NULL;
 static zend_extension *ze = NULL;

-static int suhosin_module_startup(zend_extension *extension);
-static void suhosin_shutdown(zend_extension *extension);
-
-
+static void (*orig_module_activate)(void) = NULL;
+static void (*orig_module_deactivate)(void) = NULL;
 static void (*orig_op_array_ctor)(zend_op_array *op_array) = NULL;
 static void (*orig_op_array_dtor)(zend_op_array *op_array) = NULL;
 static void (*orig_module_shutdown)(zend_extension *extension) = NULL;
 static int (*orig_module_startup)(zend_extension *extension) = NULL;

-
+static void suhosin_module_activate(void);
+static void suhosin_module_deactivate(void);
 static void suhosin_op_array_ctor(zend_op_array *op_array);
 static void suhosin_op_array_dtor(zend_op_array *op_array);
+static void suhosin_shutdown(zend_extension *extension);
+static int  suhosin_module_startup(zend_extension *extension);

 STATIC zend_extension suhosin_zend_extension_entry = {
    "Suhosin",
@@ -67,8 +68,8 @@
    "Copyright (c) 2007-2014",
    suhosin_module_startup,
    suhosin_shutdown,
-   NULL,
-   NULL,
+   suhosin_module_activate,
+   suhosin_module_deactivate,
    NULL,
    NULL,
    NULL,
@@ -80,6 +81,20 @@
    STANDARD_ZEND_EXTENSION_PROPERTIES
 };

+static void suhosin_module_activate(void)
+{
+   TSRMLS_FETCH();
+
+   suhosin_hook_post_handlers(TSRMLS_C);
+}
+
+static void suhosin_module_deactivate(void)
+{
+   TSRMLS_FETCH();
+
+   suhosin_unhook_post_handlers(TSRMLS_C);
+}
+
 static void suhosin_op_array_ctor(zend_op_array *op_array)
 {
    TSRMLS_FETCH();
@@ -108,6 +123,22 @@

 /* Stealth Mode functions */

+static void stealth_module_activate(void)
+{
+   if (orig_module_activate != NULL) {
+       orig_module_activate();
+   }
+   suhosin_module_activate();
+}
+
+static void stealth_module_deactivate(void)
+{
+   if (orig_module_deactivate != NULL) {
+       orig_module_deactivate();
+   }
+   suhosin_module_deactivate();
+}
+
 static void stealth_op_array_ctor(zend_op_array *op_array)
 {
    if (orig_op_array_ctor != NULL) {
@@ -146,8 +177,6 @@
    int resid;
    TSRMLS_FETCH();

-/* zend_register_module(&suhosin_module_entry TSRMLS_CC); */
-   
    if (zend_hash_find(&module_registry, "suhosin", sizeof("suhosin"), (void **)&module_entry_ptr)==SUCCESS) {

        if (extension) {
@@ -156,10 +185,7 @@
            zend_extension ext;
            ext = suhosin_zend_extension_entry;
            ext.handle = module_entry_ptr->handle;
-           /*
-           zend_llist_add_element(&zend_extensions, &ext);
-           extension = zend_llist_get_last(&zend_extensions);
-           */
+
            extension = &suhosin_zend_extension_entry;
        }
        module_entry_ptr->handle = NULL;
@@ -177,7 +203,6 @@
    suhosin_zend_extension_entry.resource_number = resid;

    suhosin_hook_treat_data();
-   suhosin_hook_post_handlers(TSRMLS_C);
    suhosin_aes_gentables();
    suhosin_hook_register_server_variables();
    suhosin_hook_header_handler();
@@ -191,20 +216,18 @@

 static void suhosin_shutdown(zend_extension *extension)
 {
-   TSRMLS_FETCH();
-
    suhosin_unhook_execute();
    suhosin_unhook_header_handler();
-   suhosin_unhook_post_handlers(TSRMLS_C);
    /* suhosin_unhook_session(); - enabling this causes compability problems */

     if (ze != NULL) {
        ze->startup = orig_module_startup;
        ze->shutdown = orig_module_shutdown;
+       ze->activate = orig_module_activate;
+       ze->deactivate = orig_module_deactivate;
        ze->op_array_ctor = orig_op_array_ctor;
        ze->op_array_dtor = orig_op_array_dtor;
     }
-    
 }


@@ -214,7 +237,6 @@
    zend_extension *ex = &suhosin_zend_extension_entry;
    char *new_info;
    int new_info_length;
-   TSRMLS_FETCH();

    /* Ugly but working hack */
    new_info_length = sizeof("%s\n    with %s v%s, %s, by %s\n")
@@ -233,28 +255,22 @@
    /* Stealth Mode */
    orig_module_startup = ze->startup;
    orig_module_shutdown = ze->shutdown;
+   orig_module_activate = ze->activate;
+   orig_module_deactivate = ze->deactivate;
    orig_op_array_ctor = ze->op_array_ctor;
    orig_op_array_dtor = ze->op_array_dtor;

-    /*if (SUHOSIN_G(stealth) != 0) {*/
-       ze->startup = stealth_module_startup;
-       ze->shutdown = stealth_module_shutdown;
-       ze->op_array_ctor = stealth_op_array_ctor;
-       ze->op_array_dtor = stealth_op_array_dtor;
-    /*}*/
+   ze->startup = stealth_module_startup;
+   ze->shutdown = stealth_module_shutdown;
+   ze->activate = stealth_module_activate;
+   ze->deactivate = stealth_module_deactivate;
+   ze->op_array_ctor = stealth_op_array_ctor;
+   ze->op_array_dtor = stealth_op_array_dtor;

    res = old_startup(ext);

-/*    ex->name = NULL; 
-    ex->author = NULL;
-    ex->copyright = NULL;
-    ex->version = NULL;*/
-
-    /*zend_extensions.head=NULL;*/
-
    suhosin_module_startup(NULL);

-   
    return res;
 }

Regards,
NewEraCracker

In Debian we got the following bugreport, which can be reproduced by package maintainers:

To reproduce this bug:

1. Take a fresh copy of Debian Squeeze
2. Install apache2-mpm-prefork, libapache2-mod-php5 and php5-xcache
3. Run apache2ctl stop, apache2ctl start to take you to the starting point
4. Create a php-script that stores session data (session_start(), $_SESSION['foo'] = "bar";)
5. The session data in written encrypted in /lib/var/php5.
6. Restart apache with apache2ctl restart.
7. Try to read $_SESSION with session_start(). decryption will fail and no session data will be displayed. The content in the session file is deleted due to the saving of an empty session.
8. Write session data again. This time the session data is stored unencrypted.
9. Restart the system with apache2ctl stop, apache2ctl start. Now the system can't read the unencrypted session data and the data is erased again.

The problem only occurs with php5-xcache installed.

You can track the Debian Bugreport via http://bugs.debian.org/658228

Many thanks, Jan.

Building against php 5.3.20
suhosin rev:1fba865ab73cc98a3109f88d85eb82c1bfc29b37

re: https://github.com/stefanesser/suhosin/blob/master/execute.c#L641

cc -I. -I/tmp/suhosin -DPHP_ATOM_INC -I/tmp/suhosin/include -I/tmp/suhosin/main -I/tmp/suhosin -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /tmp/suhosin/execute.c -fPIC -DPIC -o .libs/execute.o

/tmp/suhosin/execute.c: In function ‘ih_preg_replace’:
/tmp/suhosin/execute.c:641: warning: ‘zend_get_parameters_ex’ is deprecated (declared at /usr/include/php/Zend/zend_API.h:229)

background : http://developers.evrsoft.com/docs/php/zend.arguments.deprecated-retrieval.shtml

zend_get_parameters_array_ex() should be used, with a refactor of the parameters into an args
further : http://developers.evrsoft.com/docs/php/zend.arguments.variable.shtml

re: https://github.com/stefanesser/suhosin/blob/master/session.c#L953

cc -I. -I/tmp/suhosin -DPHP_ATOM_INC -I/tmp/suhosin/include -I/tmp/suhosin/main -I/tmp/suhosin -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /tmp/suhosin/session.c -fPIC -DPIC -o .libs/session.o

/tmp/suhosin/session.c: In function ‘suhosin_hook_session’:
/tmp/suhosin/session.c:953: warning: assignment discards qualifiers from pointer target type

Hi,

My question is does Suhosin impose a maximum memory_limit that php scripts can alter the value to even if your php.ini memory_limit value contains -1, which should be allowing PHP scripts to alter the memory_limit to whatever it wants?

So, I have a PHP script running with the code

ini_set('memory_limit', '2048M');

Which results in alerts being logged such as the following

"script tried to disable memory_limit by setting it to a negative value -1 bytes which is not allowed"

Someone else investigating a similar issue mentioned there may be a higher limit

http://forums.fedoraforum.org/showthread.php?t=260640

I too checked the source code and only found a mention of a hard_memory_limit, 1<<30 (128MB right?)

As far as I can tell the script still runs and I'm in the process of just changing this value to 2046M, but is this upper limit of 2048M something that exists?

...

Hello,

This code in suhosin_execute_ex is executed multiple times per request if the current php file running has multiple include/require. In my case it has caused over 20 reports per each violation, and sometimes php even segfaults.

/* log variable dropping statistics */
if (SUHOSIN_G(abort_request) && (SUHOSIN_G(att_request_variables)-SUHOSIN_G(cur_request_variables) > 0)) {
    suhosin_log(S_VARS, "dropped %u request variables - (%u in GET, %u in POST, %u in COOKIE)",
    SUHOSIN_G(att_request_variables)-SUHOSIN_G(cur_request_variables),
    SUHOSIN_G(att_get_vars)-SUHOSIN_G(cur_get_vars),
    SUHOSIN_G(att_post_vars)-SUHOSIN_G(cur_post_vars),
    SUHOSIN_G(att_cookie_vars)-SUHOSIN_G(cur_cookie_vars));
}

I had to move this code to suhosin.c RSHUTDOWN stage before the cleaning of the input filtering variables takes place. That way violations are only logged once.

Regards,
NewEraCracker

Only on my gallery3 installation, session writes seem to fail with the latest suhosin-dev. I am not sure if this is an error in Suhosin or the gallery3 session handler, but here goes the stacktrace:

Fatal error: Uncaught exception 'ErrorException' with message 'session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php5)' in /home/www/htdocs/gallery3.christopher-kunz.de/system/libraries/Session.php:325 Stack trace: #0 [internal function]: gallery_error_Core::error_handler(2, 'session_write_c...', '/home/www/htdoc...', 325, Array) #1 /home/www/htdocs/gallery3.christopher-kunz.de/system/libraries/Session.php(325): session_write_close() #2 [internal function]: Session_Core->write_close(NULL) #3 /home/www/htdocs/gallery3.christopher-kunz.de/system/core/Event.php(208): call_user_func_array(Array, Array) #4 /home/www/htdocs/gallery3.christopher-kunz.de/system/core/Kohana.php(549): Event_Core::run('system.shutdown') #5 [internal function]: Kohana_Core::shutdown() #6 {main} thrown in /home/www/htdocs/gallery3.christopher-kunz.de/system/libraries/Session.php on line 325

All encryption parameters in Suhosin are deactivated and sessions are stored in the clear. /var/lib/php5 contains valid sessions from my other applications. Disabling Suhosin removes the fatal error.

The following script causes PHP to crash when Suhosin is enabled.
Reproduced in PHP 5.3.28 and PHP 5.4.30.

<?php
ini_set('memory_limit', '8M');
class DestructableObject
{
    public function __destruct()
    {
        DestructableObject::__destruct();
    }
}
class DestructorCreator
{
    public function __destruct()
    {
        $this->test = new DestructableObject;
    }
}
class Test
{
    public static $mystatic;
}
$x = new Test();
Test::$mystatic = new DestructorCreator();
?>

This script was taken from PHP.NET bug #54268 (Double free when destroy_zend_class fails)

Hi,

There is an issue when we try to use the function suhosin.executor.eval.blacklist, please see the samples below:

eval(system("echo 'Test 1\n';")); // not working
eval('system("date");'); // working
eval(base64_decode("ZWNobyAiVGVzdCAxIFxuIjs=")); // not working
eval(eval('base64_decode("ZWNobyAiVGVzdCAxIFxuIjs=");')); // working

Apparently this function just works when arguments are between quotes.

All tests were made using suhosin as extension and the version of PHP was 5.4.24.

Is this behavior expected?

Hello, the time suhosin logs is 3 hours behind the rest of the server. How can I change that?

Kind regards,
Manos K

updated 2012-07-16 see #14 ("just as a reminder that PHP 5.4.x is not yet supported.")

Suhosin 0.9.33

After migration to PHP 5.4.4
I did

cd suhosin
phpize
./configure
make
install

and got

php --version
PHP Warning:  \
PHP Startup: Unable to load dynamic library \
'/usr/share/extensions/no-debug-non-zts-20100525/suhosin.so' - /usr/share/extensions/no-debug-non-zts-20100525/suhosin.so: undefined symbol: output_globals in Unknown on line 0
PHP 5.4.4 (cli) (built: Jun 16 2012 23:09:01)

post_handler.c Line 74

if (sapi_module.input_filter(PARSE_POST, var, &val, new_val_len, &new_val_len TSRMLS_CC)) {

I think it should be

if (sapi_module.input_filter(PARSE_POST, var, &val, val_len, &new_val_len TSRMLS_CC)) {

As I can see in http://lxr.php.net/xref/PHP_5_5/main/php_variables.c#259

Using Suhosin 0.9.34-dev.

I've posted the build failure log in pastebin at : http://pastebin.com/raw.php?i=pB6etkay

hello friends, i just got my php5.4 from ppa under ubuntu 12.04 working with apache 2.4 mod_proxy_fcgi but i am having an issue after applying MB_STRING patch from jani@e8beb4f:

• the suhosin compiles ok with no errors under php5.4.11
• the php / php-fpm seems to run correctly
• BUT i get an error "Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/tmp) in /srv/www/...../libraries/joomla/session/session.php on line 633 "
• once i disable suhosin, the session works and i am able to login in, etc..

i hope this report will help.
best regards,
stan

PHP 5.4.11-1~precise+1 (cli) (built: Jan 24 2013 14:02:41)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with XCache v2.0.1, Copyright (c) 2005-2012, by mOo
with Suhosin v0.9.34-dev, Copyright (c) 2007-2012, by SektionEins GmbH

After updating from suhosin-0.9.33 to suhosin-0.9.35, I'm seeing apache
child segfaults when a request triggers suhosin "configured GET variable
value length limit exceeded". At the moment, this issue only happens
on drupal sites.

Version info:

• RHEL5 apache httpd(2.2.x)
• PHP Version 5.3.28 (from IUS repository)

If I re-compile suhosin-0.9.35 and remove the new "log variable dropping
statistics" section in log.c, it no longer segfaults.

I have not been able to develop a minimal PHP test case which causes this.

httpd core dump shows:

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x00dc5389 in suhosin_log (loglevel=4, fmt=0xdcf4d4 "dropped %u
request variables - (%u in GET, %u in POST, %u in COOKIE)")
at /tmp/suhosin-0.9.35/log.c:167
167 lineno = exdata->opline->lineno;
(gdb) q

I was trying to install on a production server a symfony application for the first time.
This server is a Debian wheezy 7, amd64 port, with standard PHP version (5.4.4) and with suhosin 0.9.35.
Symfony (version 2.3.13 lts) is working fine without the suhosin extension.
When we enable suhosin, in simulation mode and with phar in the executor whitelist, it doesn't work anymore.
Unfortunately we got nothing in the logs: only the apache error log signals a segmentation fault for one of his child processes.
Any ideas? Suggestions?

Just as a reminder that PHP 5.4.x is not yet supported.

Current tree compiles against it, without disabling features.

However some problems with the dropped variable statistics and the session module.

PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:11:57)

PHP.INI
suhosin.executor.func.whitelist="__construct,array_keys,date,define,htmlspecialchars,join,mktime,pi,pow,print_r,sort,ksort,strptime,time"

Script:

According to source headers:

  | This source file is subject to version 3.01 of the PHP license,      |
  | that is bundled with this package in the file LICENSE, and is        |
  | available through the world-wide-web at the following url:           |
  | http://www.php.net/license/3_01.txt                                  |

But the LICENSE file didn't exists

More, from PHP License

  2. Redistributions in binary form must reproduce the above copyright

So any binary distribution of this extension violates its License...

So please provides the LICENSE file, thus making every downstream distributor happy.

Bugreport by email:

It seems that "suhosin.executor.include.whitelist" does not support dots in
schema name (at least in my version, distributed with debian), example:
"zend.view://"

This schema name is used in Zend Framework (Zend_View).

Dragan

Attempt to build php with:
configure --disable-all --enable-cli --enable-session --enable-zlib --enable-object-out-dir="." --enable-one-shot --enable-suhosin="shared"

Error:
ext\suhosin\post_handler.c(171) : error C2065: 'tsrm_ls' : undeclared identifier
ext\suhosin\post_handler.c(174) : error C2065: 'tsrm_ls' : undeclared identifier

If I add TSRMLS_FETCH(); after zend_ini_entry *ini_entry; on line 168 build no longer fails.
I don't know if this change is appropriate or not but seems to fix the issue for me.

title says it all

If an attacker/web application tries to send more than the configured limit of variables the log message just says that variables were dropped. Some people want to know the number of variables that were actually sent, so that they do not need to do trial and error how much they should raise the limit.

Have to check if we can do that without running into other problems.

Regarding to http://stackoverflow.com/a/3384117 a mere check may fail on certain installations.

Is this true ?

Is the following if ( ini_get () ) a reliable solution to check whether Suhosin patch, extension, built-in extension is active at that moment ?

if ( ini_get( "suhosin.get.max_value_length" ) ) { 
   // yes, suhosin is active ...
   // do something meaningful with the value of ini_get( "suhosin.get.max_value_length" )
 }

Hi there,

most of your code is licensed under the ´PHP License, version 3.01´.

There is a discussion over there in the Debian project, if software is redistributable if it´s licensed under this license and it comes not from the "PHP Group". While in the first place this looks like just a Debian (and maybe other distributions) problem, it may also affect this software project itself.

A valuation of the Debian FTP-Team, not only affecting redistribution in Debian, can be found here:

https://lists.debian.org/debian-legal/2005/08/msg00128.html
https://lists.debian.org/debian-legal/2006/02/msg00215.html

It would be cool, if you could relicense your work to a license which allows others to redistribute your work and don´t gives potential troubles yourself.

A close license to your actual one maybe:

• BSD
• MIT/Expat

Many thanks, Jan.

It would be nice to have each version of suhosin being tagged in git. This makes it easier to spot differences between versions, do regression tests and a lot of other useful things.

Hi,

I'm trying to compile Suhosin extension (0.9.35) on Windows for PHP 5.5.10.

I can build PHP 5.5.10 without Suhosin just fine. If I extract the Suhosin code and run configure like this:

configure --disable-all --enable-cli --enable-suhosin

in the PHP source directory (where \suhosin-0.9.35\ is), I get the following errors when running nmake:

suhosin-0.9.35\execute.c(1331) : warning C4101: 'fd': Unreferenzierte lokale Variable
suhosin-0.9.35\execute.c(1620) : error C2143: Syntaxfehler: Es fehlt ';' vor 'Typ'
suhosin-0.9.35\execute.c(1621) : error C2143: Syntaxfehler: Es fehlt ';' vor 'Typ'
suhosin-0.9.35\execute.c(1622) : error C2275: 'zend_class_entry': Ungültige Verwendung dieses Typs als Ausdruck
Zend\zend.h(302): Siehe Deklaration von 'zend_class_entry'
suhosin-0.9.35\execute.c(1622) : error C2065: 'ce': nichtdeklarierter Bezeichner
suhosin-0.9.35\execute.c(1623) : error C2275: 'internal_function_handler': Ungültige Verwendung dieses Typs als Ausdruck

Can anyone tell me what I'm doing wrong, or point me to a tutorial on how to install Suhosin under Windows?

Thanks a lot

Paul

See session.c line 959 to 969.

/* increase session identifier entropy */
if (SESSION_G(entropy_length) == 0 || SESSION_G(entropy_file) == NULL) {

    /* ensure that /dev/urandom exists */
    int fd = VCWD_OPEN("/dev/urandom", O_RDONLY);
    if (fd >= 0) {
        close(fd);
        SESSION_G(entropy_length) = 16;
        SESSION_G(entropy_file) = pestrdup("/dev/urandom", 1);
    }
}

The code should be disabled in the Windows platform by adding #ifndef PHP_WIN32 before it and #endif after it.

An example of the correct approach can be seen at execute.c at line 1301 to 1308

#ifndef PHP_WIN32
    fd = VCWD_OPEN("/dev/urandom", O_RDONLY);
    if (fd >= 0) {
        /* ignore error case - if urandom doesn't give us any/enough random bytes */
        read(fd, &seedbuf[6], 2 * sizeof(php_uint32));
        close(fd);
    }
#endif

Suhosin should disallow php://fd/XXX by default, because it is a bad idea

It might introduce a "override configuration option" and add allow_url_include check.

During MINIT -> php_stream_locate_url_wrapper and hook the php:// handler

Hello!

Thanks for your project to make php safer but I got a fail when I make test. I'm on CentOS 6.5 32bits with php5.5. I have no idea how to solve it and I don't know if I should continue to install Suhosin. I hope you can help!

Here is one of the outputs:

PASS Testing: suhosin.upload.disallow_binary=On with UTF-8 and allow_utf8=Off [tests/filter/suhosin_upload_disallow_binary_utf8fail.phpt]

TEST RESULT SUMMARY
Exts skipped : 0
Exts tested : 17

Number of tests : 173 153
Tests skipped : 20 ( 11.6%) --------
Tests warned : 0 ( 0.0%) ( 0.0%)
Tests failed : 1 ( 0.6%) ( 0.7%)
Expected fail : 0 ( 0.0%) ( 0.0%)
Tests passed : 152 ( 87.9%) ( 99.3%)

Time taken : 5 seconds

FAILED TEST SUMMARY
Testing: suhosin.upload.disallow_binary=On [tests/filter/suhosin_upload_disallow_binary_on.phpt]

Yours,
Roderick

// "suhosin.memory_limit = 128M" in php.ini

// app is setting it's initial memory limit
ini_set('memory_limit', '32M');
echo 'LIMIT1: ' . ini_get('memory_limit');

// image processing require more memory
ini_set('memory_limit', -1);
echo 'LIMIT2: ' . ini_get('memory_limit');

When I've set memory_limit initially, then any attempt to use "-1" as new memory_limit will result in usage of memory_limit set before, not maximal allowed by shosin.

However if I remove initial memory_limit of 32M, then setting to -1 would set it correctly to 128M.

PHP: 5.3.17
Suhosin: 0.9.34-dev

The problem happens when you are using PHP 5.2. The suhosin copy_request_variable in ex_imp.c

Here it is declared that new_key is a char.

    char *prefix, *new_key;

Here we see misuse of zval_dtor.

    if (php_varname_check(new_key, new_key_len-1, 0 TSRMLS_CC) == FAILURE) {
        zval_dtor(&new_key);
        return 0;
    }

That code should be corrected to:

    if (php_varname_check(new_key, new_key_len-1, 0 TSRMLS_CC) == FAILURE) {
        efree(new_key);
        return 0;
    }

Caution should be taken when fixing, as this should only touch PHP 5.2 code. The line number that should be corrected is 553.

Regards,
NewEraCracker

Add support for the "use session identifier to crypt session and use alternative session identifier for storage idea" from Jürgen.

I just cloned the latest suhosin from git and tried to compile on PHP 5.4.3 and here's what i got
suhosin/treat_data.c:197:2: error: too few arguments to function ‘sapi_register_treat_data’
In file included from /home/willysr/suhosin/treat_data.c:30:0:
/usr/local/include/php/main/SAPI.h:197:14: note: declared here
make: *** [treat_data.lo] Error 1

Slackware-Current
GCC 4.7.0
PHP 5.4.3

I have a question regarding commit 22281ed changes in post_handler.c

            if (suhosin_input_filter(PARSE_POST, var, &val, val_len, &new_val_len TSRMLS_CC)) {
#ifdef ZEND_ENGINE_2
                if (sapi_module.input_filter(PARSE_POST, var, &val, new_val_len, &new_val_len TSRMLS_CC)) {

Was changed to

            if (sapi_module.input_filter(PARSE_POST, var, &val, val_len, &new_val_len TSRMLS_CC)) {

Is this change intended?

execute.c - Line 1103:
efree(lcname);

execute.c - Line 1117
if (!zend_hash_exists(SUHOSIN_G(eval_whitelist), lcname, func_name_len+1)) {

There are, more uses in line 1121, 1128 and 1132.

I've refactored ih_function_exits code, but as of now is untested:
http://pastebin.com/kgxgkKRE

Currently many PHP applications are vulnerable to XML Injection attacks as documented here: http://phpsecurity.readthedocs.org/en/latest/Injection-Attacks.html#xml-injection

As this is a widespread issue I think adding mitigation to those attacks in Suhosin would benefit many users so I am wondering if there are any plans to do so.

Regards,
NewEraCracker

Hello mate,
I found that most of web server administrators use cPanel as a control panel for shared hosting,so this suhosin.sql.user.prefix is useless because of any MySQL database consists of 2 parts separated with "_".
e.g: if you have database called vb ,it must have name : cpaneluser_vb and its MySQL User is cpaneluser_DBUserName

so what I suggest is creating an option to prevent any other cpanel user to use the database of other user.
for example:
if we have 2 cPanel Users each one have home directory and have its own databases
cpaneluser1_DB with its MySQL User cpaneluser1_DBUserName
and the other cpanel user has cpaneluser2 _DB with its MySQL User cpaneluser2_DBUserName

we want to prevent the cpaneluser2 to use cpaneluser1_DBUserName even if he knows login details of cpaneluser1_DBUserName and its password

Thank You

trying to build 0.9.35, with php-5.5.11 i get error:

/home/users/glen/rpm/packages/BUILD.x86_64-linux/suhosin-0.9.35/log.c: In function 'suhosin_log':
/home/users/glen/rpm/packages/BUILD.x86_64-linux/suhosin-0.9.35/log.c:120:26: error: 'S_GETCALLER' undeclared (first use in this function)
  getcaller = (loglevel & S_GETCALLER) == S_GETCALLER;
                          ^
/home/users/glen/rpm/packages/BUILD.x86_64-linux/suhosin-0.9.35/log.c:120:26: note: each undeclared identifier is reported only once for each function it appears in
Makefile:218: recipe for target 'log.lo' failed
make: *** [log.lo] Error 1

S_GETCALLER is defined in https://github.com/stefanesser/suhosin/blob/suhosin-0.9.35/php_suhosin.h#L289 if S_MEMORY is not defined, but S_MEMORY is defined by Zend/zend_errors.h

commit 3142dc0 which added it, doesn't indicate is this constant suhosin internal use, or it existed in early 5.5 code.

i see two ways to fix this:

• reorder #include directives so Zend is included after local defin
• move S_GETCALLER outside ifdef so it's always defined

however if that parameter should drive zend code, it should be rather defined to 0 if not defined after the define of S_xxx block

When a function is blacklisted, the only way to properly detect that is by handling the output of ini_get('suhosin.executor.func.blacklist'). This is a pain to do when you need multiple checks and makes function_exists() and is_callable() practically useless when you want to determine if e.g. exec() can be called safely.

Also, terminating script execution when a blacklisted function is executed isn't the most ... friendly approach. Returning FALSE, NULL, etc. would be way more convenient.

I'm no C coder and I'm not familiar with the PHP internals, so I don't know if those two behaviors are even possible, but to better understand why they are important I'll explain how it got my attention.

I'm a CodeIgniter Reactor engineer and for better detection of MIME types on file uploads, we utilize dangerous functions like exec(), popen() and system() to call /usr/bin/file, when they are available.
Now, I see that the Suhosin extension has a way of handling this stuff, but with CodeIgniter being a framework and largely used in shared-hosting environments, in most cases it's not even possible to have somebody configure suhosin.upload.verification_script. And even if so - the function blacklist still makes it almost impossible to work out of the box.

I know this is all configurable, but I still believe that it would be way better if at least one of the two feature requests above could be satisfied. Should even make Suhosin more popular and easier to adopt.

As far as I can see this was the commit the PHP developers have done:
http://svn.php.net/viewvc?view=revision&revision=312103

While inspecting suhosin's rfc1867.c I found similar code so I am wondering if suhosin is vulnerable to this or not.

I would like to know if the secureconfig patch (referenced http://php-security.org/2010/05/22/mops-submission-08-configuration-encryption-patch-for-suhosin/index.html) is going to be incorporated into the Suhosin extension code. I have my own packaged 9.31 php-suhosin RPM with the patch included, but would like to see it included in trunk, since that's really the main feature we started using suhosin for in our environment.

Thanks,
RobertC

(welcome back, very glad to see new work being done on Suhosin again)

Are the failed tests just suhosin code still catching up from php 5.3 to the newer 5.5 and 5.6 ?

I get 77 passed and 97 failed against both php 5.5 and 5.6 when running make test

Is it just because I need to be patient and wait for the codebase to catch up or is there something wrong with my configuration perhaps?

Things like this fail:
cookie encryption
suhosin GET filter
suhosin input filter
and several other areas.

However things like the EVAL disable work great including all other suhosin.executor features so that right there makes it immediately practical.

I noticed some tests are skipifcli - is there another way to run make test that is not CLI? Does it use the new webserver inside php?

Maybe that is why there are so many failed tests, I do not think it is detecting cli mode or skipping properly - I get Tests Skipped 0 and I do not think things like GET can be tested properly in CLI