PHP vulnerabilities

[webfeatus]

I understand that this is a lot to ask. But is there anyone out there who is prepared to help me go through this, step by step?
https://www.atomicorp.com/wiki/index.ph ... _warn_only

[faris]

What do you need exactly?

ASL can automatically fix the PHP vulnerabilities being listed in its report by disabling certain functions.

Or do you need an explanation of each vulnerability?

Or something else?

[webfeatus]

Or do you need an explanation of each vulnerability?

Yes, was wondering if I could go through each vulnerability that I do not understand or I am not sure about. Some I may have to ask my programmer fist. Some I will understand and some I will have to ask a question about.

[webfeatus]

I suspect that the steps would be:
1. Enable all vulnerabilities that I am not sure about.
2. Turn off warn only.
3. Go through each remaining vulnerability one by one.

[faris]

Can you post the list?

Or are you seeing something like this:

PHP: function curl_exec() allows an attacker to execute shell commands through php.
Read More...
PHP: function curl_multi_exec() allows an attacker to execute shell commands through php.
Read More...
PHP: Function dl() allows an attacker to load their own extension into php.
Read More...
PHP: function exec() allows an attacker to execute shell commands through php.
Read More...
PHP: function eval() allows an attacker to execute arbitrary PHP code..
Read More...
PHP: Function fsockopen() allows an attacker to open sockets, useful for spamming, remote inclusion, etc.
Read More...
PHP: function ini_alter() is an alias for ini_set.
Read More...
PHP: function ini_set() Sets the value of a configuration option.
Read More...
PHP: Function passthru() allows an attacker to execute shell commands through php.
Read More...
PHP: function pcntl_exec() allows an attacker to execute shell commands through php.
Read More...
PHP: Function pfsockopen() allows an attacker to open sockets, useful for spamming, remote inclusion, etc.
Read More...
PHP: Function popen() allows attacker to execute commands on a system.
Read More...
PHP: Function posix_kill() is enabled. This allows an attacker to kill processes of the webserver user.
Read More...
PHP: Function posix_mkfifo() creates a special FIFO file which exists in the file system and acts as a bidirectional communication endpoint for processes.
Read More...
PHP: function posix_setuid() sets the UID of the current process.
Read More...
PHP: function proc_close() Close a process opened by proc_open() and return the exit code of that process.
Read More...
PHP: function proc_open() is enabled. Execute a command and open file pointers for input/output. Allows an attacker to execute commands on the system.
Read More...
PHP: function proc_terminate() Kills a process opened by proc_open.
Read More...
PHP: Function shell_exec() enabled. Execute command via shell and return the complete output as a string. This allows an attacker to execute commands on the system.
Read More...
PHP: Function allowed: system() allows an attacker to execute commands on the system.
Read More...
PHP: function ftp_exec() allows an attacker to execute shell commands through php.
Read More...

url_fopen is another one that may be in your list.


Effectively, NONE of these normally need to be enabled. There's no real point going through them individually. They are rarely used functions that as a rule of thumb you would not want a typical script to have access to.

Of course it is possible that you might have one or two customers who have a legitimate reason to need one or two of these, and you can enable them for those specific clients if need be and you feel the risk is worth it.

Or have I misunderstood and you were thinking about something else?

[webfeatus]

I have "removed" all the PHP vulnerabilities except those listed below.
I completed this over time and am still monitoring the server for any more unforeseen consequences.
Several of the vulnerabilities listed below must remain due to server processes.
[example: fsockopen() must stay]
In many cases I evaluated each one using the "read more" link to atomic KB.
Most of these remaining have no KB information.

Can you tell me if any of these look like they could definitely be removed?
i.e. unlikely to have any significant consequences.


PHP: function eval() allows an attacker to execute arbitrary PHP code..

PHP: Function fsockopen() allows an attacker to open sockets, useful for spamming, remote inclusion, etc.

PHP: function ini_alter() is an alias for ini_set.

PHP: function ini_set() Sets the value of a configuration option.

PHP: function link() allows an attacker to create hard links on the system.

PHP: Function allowed: symlink() allows an attacker to create symbolic links on the system.

PHP: function allowed apache_child_terminate(). Terminate apache process after this request.

PHP: function allowed apache_setenv(). Set an Apache subprocess_env variable.

PHP: allowed function define_syslog_variables(). Initializes all syslog related variables.

PHP: function ftok() Convert a pathname and a project identifier to a System V IPC key.

PHP: Function escapeshellarg() is enabled.

PHP: allowed function highlight_file(). Syntax highlighting of a file

PHP: function ini_get_all() Gets all configuration options.

PHP: Function openlog() allows an attacker to open a connection to the system logger.

PHP: Function posix_access() is enabled. Determine accessibility of a file.

PHP: Function posix_getpwuid() is enabled. Return info about a user by user id.

PHP: function posix_uname() Returns system information.

PHP: function allowed readlink(). Returns the target of a symbolic link.

PHP: Function allowed: syslog() allows an attacker to generate log events.

[faris]

Out of all of those, I only spotted one that might potentially be used by the kind of script a customer might want to run (but rarely): fsockopen()

It should, however, be disabled by default and only enabled if a specific customer needs it for a specific purpose.

OSSEC should be able to spot scripts that try to run disabled functions and generate an alert. I think there's already a rule for it, but I can't seem to find it with a simple search in the HIDS rules.