sektioneins / pcc Goto Github PK

The PHP.ini could be checked against loaded modules like zend_extension=xdebug.so. Xdebug for example is commonly used but should not be available in production environment. Is such a check wished?

Hi,

The warning message about not logging error is "You are not logging errors." and I aggree it should be activated. So I suppose line 346 should be :
if(!is_on($v)) {

instead of
if(is_on($v)) {

error_log: /home/web/log/php.log
doc_root: /home/web/public_html/server

The constant STDOUT is only defined if PHP is called in CLI mode.
In line 1367 the constant STDOUT is used unconditionally which leads to warning or even error messages if PHP is not called in CLI mode.
Dubious use is: if (function_exists('posix_isatty') && posix_isatty(STDOUT)) {
Safe use could be: if (function_exists('posix_isatty') && defined('STDOUT') && posix_isatty(STDOUT)) {

I'm experimenting with Version 0.1-dev11 and it's reporting:

[*] This script is rather old. Please check for updates:
https://github.com/sektioneins/pcc

Is there a later version that I'm somehow missing? I see there have been minor updates as recently as six months ago - is there further development being done on this script?

We'd like to feature it on linuxsecurity.com.

In line 645 the non-existing variable $is_win is used. It should be $cfg['is_win'] instead.

I had tried the script but some values are not shown corectly.

from command line

php -i | grep suhosin.request.disallow_nul
suhosin.request.disallow_nul => 1 => 1

and your script recommends

[high ] php.ini / suhosin.request.disallow_nul
nul-protection off.
Unless binary data is handled unencoded - which would be very obscure - this feature wants to remain enabled.

The problem seem to be with all of the following:

php.ini / suhosin.cookie.disallow_nul
php.ini / suhosin.get.disallow_nul
php.ini / suhosin.post.disallow_nul
php.ini / suhosin.request.disallow_nul

php version:
PHP 5.4.30 (cli) (built: Jun 27 2014 11:59:31)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with the ionCube PHP Loader v4.4.1, Copyright (c) 2002-2013, by ionCube Ltd.
with Suhosin v0.9.36, Copyright (c) 2007-2014, by SektionEins GmbH

Just wondering, for example under PHP 8.x there's a deprecation warning at line 1098 about return "\033[${color}m$result\033[0m"; (fixable with {$color})

Hi,
First of all, thank you for this initiative.
I just install a default Linux Debian 7.7 with Apache and PHP 5.4 and in the php.ini file it is written :
enable_dl = Off
which seems fine to me but when using your script, it still give me a high risk on enable_dl.

Looking at phpinfo() function I've got
enable_dl Off
witch seems also correct.

Looking at your script, and trying to debug it, it seems that the problem comes from the usage of ini_get_all function.

print_r(ini_get_all()); give me this kind of thing
[enable_dl] => Array ( [global_value] => [local_value] => [access] => 4 )

As you see, there seems to be no value at all.

If I put 0 in the php.ini the ini_get_all function return 0
If I put 1 in the php.ini the ini_get_all function return 1
If I put Off or off in the php.ini the ini_get_all function return nothing
If I put On or on in the php.ini the ini_get_all function return 1

This problem is not only for enable_dl, it's a global problem.

If running PHP 7.x and hence using snuffleupagus instead of suhosin the following check in line 1249 causes the whole script to abort if the default snuffleupagus ruleset is active:
test_log_in_document_root('suhosin.log.file.name')
The reason is that test_log_in_document_root calls ini_get('suhosin.log.file.name') and the default snuffleupagus ruleset forbids to call ini_get() for any suhosin parameters.
This could possibly be improved by replacing line 1249 with the following code:
extension_loaded('suhosin') && test_log_in_document_root('suhosin.log.file.name')

Bravo! Nicely done, and very handy auditing tool.

pcc tells me:

suhosin.log.file.name in document root
Checks if suhosin.log.file.name path is in the current document root

I have not installed the module or the patch.

OS: OS/2
Apache: 2.2.29
PHP: 5.4.36 (as module)

In line 792 the test for intl.error_level is logically wrong.
It is: intval($v) | E_ERROR which always yields true regardless of the value of $v.
It should be: intval($v) & E_ERROR

Hi. I know that one point of the basic idea of this library is:

NO complicated/overengineered code, e.g. no classes/interfaces, test-frameworks, libraries, ... -> It is supposed to be obvious on first glance - even for novices - how this tool works and what it does!

But I think it should be great if the library had some basic support for composer, for easy distribution and use. So, for "advanced users", they can install the library with composer and then execute it with some code like:

require 'vendor/autoload.php';

Pcc::check();

And for novices, just execute the php file phpconfigcheck.php that launch the class and print the result.

I'm no whiz at Github, so I'll just paste my diff:

diff -u2 original/phpconfigcheck.php updated/phpconfigcheck.php
--- original/phpconfigcheck.php 2015-01-07 21:47:04.000000000 -0500
+++ updated/phpconfigcheck.php  2015-01-07 21:50:56.000000000 -0500
@@ -239,5 +239,5 @@
        'max_input_time' => "It may be useful to limit the time a script is allowed to parse input. This should be decided on a per application basis.",
        'max_input_nesting_level' => "Deep input nesting is only required in rare cases and may trigger unexpected ressource limits.",
-       'memory_limit' => "A high memory limit may easy lead lead to ressource exhaustion and thus make your application vulnerable to denial-of-service attacks. This value should be set approximately 20% above empirically gathered maximum memory requirement.",
+       'memory_limit' => "A high memory limit may easily lead to resource exhaustion and thus make your application vulnerable to denial-of-service attacks. This value should be set approximately 20% above an empirically gathered maximum memory requirement.",
        'post_max_size' => "Setting the maximum allowed POST size to a high value may lead to denial-of-service from memory exhaustion. If your application does not need huge file uploads, consider setting this option to a lower value. Note: File uploads have to be covered by this setting as well.",
        'post_max_size>memory_limit' => "post_max_size must be lower than memory_limit. Otherwise, a simple POST request will let PHP reach the configured memory limit and stop execution. Apart from denial-of-service an attacker may try to split a transaction, e.g. let PHP execute only a part of a program.",

Thanks again for this handy tool!

Do we want to check if specific functions are present, like proc_open or setenv?
Those are dangerous and shouldn't be available in production.