Related
We have a large codebase, and every so often a var_dump used for testing and not removed/commented suddenly appears out of nowhere. There is a messy solution using XDebug (http://devzone.zend.com/1135/tracing-php-applications-with-xdebug/), but maybe there's something ingenous that can be done in PHP at runtime.
Also, I don't want to modify or search code via regex. I've tried using my own var_dump_v2, but it falls out of use quickly.
Is it possible to use the disable_functions operation in php.ini to disable var_dump on your production server? I am not sure what the outcome of this setting is (ie does it fail with an error, or silently) the documentation is not so clear.
http://php.net/manual/en/ini.core.php - see "disable_functions"
Also there is override_function:
<?php
override_function('var_dump', '$a', 'return 0;');
?>
http://php.net/manual/en/function.override-function.php
There are actually ways to do this, if you have PECL available and runkit installed. You kan make runkit able to overide PHPs internal functions if you in php.ini set runkit.internal_override to "1".
For removing the var_dump function, you could use:
runkit_function_remove('var_dump');
In your case, not to get an error, you should probably instead use something like this:
runkit_function_redefine('var_dump', '','');
Take a look at the runkit extensions documentation here.
You may also want to take a look at "Advanced PHP debugger", another extension that seems to offer an override_function().
You can use monkey patching.
Just defines a namespace on the first line of your file and defines the function var_dump
<?php
namespace monkey;
function var_dump($obj) {}
Of course, it implies that you do not use a namespace in your current file
You could use the function var_dump() prefixing it with the root namespace(): \var_dump()
Of course, all others native function will continue to work as usual as long as you do not override them in your namespace.
Why don't you use serialize() or json_encode() if you have a large database? That will be very useful.
But take note, serialize() will give you a 1-line output somewhat like this:
's:0:"";s:5:"value";'
So you need to learn the anatomy of serialize() to use it: PHP Serialize
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I'm trying to build a list of functions that can be used for arbitrary code execution. The purpose isn't to list functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have a grep-able list of red-flag keywords handy when searching a compromised server for back-doors.
The idea is that if you want to build a multi-purpose malicious PHP script -- such as a "web shell" script like c99 or r57 -- you're going to have to use one or more of a relatively small set of functions somewhere in the file in order to allow the user to execute arbitrary code. Searching for those those functions helps you more quickly narrow down a haystack of tens-of-thousands of PHP files to a relatively small set of scripts that require closer examination.
Clearly, for example, any of the following would be considered malicious (or terrible coding):
<? eval($_GET['cmd']); ?>
<? system($_GET['cmd']); ?>
<? preg_replace('/.*/e',$_POST['code']); ?>
and so forth.
Searching through a compromised website the other day, I didn't notice a piece of malicious code because I didn't realize preg_replace could be made dangerous by the use of the /e flag (which, seriously? Why is that even there?). Are there any others that I missed?
Here's my list so far:
Shell Execute
system
exec
popen
backtick operator
pcntl_exec
PHP Execute
eval
preg_replace (with /e modifier)
create_function
include[_once] / require[_once] (see mario's answer for exploit details)
It might also be useful to have a list of functions that are capable of modifying files, but I imagine 99% of the time exploit code will contain at least one of the functions above. But if you have a list of all the functions capable of editing or outputting files, post it and I'll include it here. (And I'm not counting mysql_execute, since that's part of another class of exploit.)
To build this list I used 2 sources. A Study In Scarlet and RATS. I have also added some of my own to the mix and people on this thread have helped out.
Edit: After posting this list I contacted the founder of RIPS and as of now this tools searches PHP code for the use of every function in this list.
Most of these function calls are classified as Sinks. When a tainted variable (like $_REQUEST) is passed to a sink function, then you have a vulnerability. Programs like RATS and RIPS use grep like functionality to identify all sinks in an application. This means that programmers should take extra care when using these functions, but if they where all banned then you wouldn't be able to get much done.
"With great power comes great responsibility."
--Stan Lee
Command Execution
exec - Returns last line of commands output
passthru - Passes commands output directly to the browser
system - Passes commands output directly to the browser and returns last line
shell_exec - Returns commands output
`` (backticks) - Same as shell_exec()
popen - Opens read or write pipe to process of a command
proc_open - Similar to popen() but greater degree of control
pcntl_exec - Executes a program
PHP Code Execution
Apart from eval there are other ways to execute PHP code: include/require can be used for remote code execution in the form of Local File Include and Remote File Include vulnerabilities.
eval()
assert() - identical to eval()
preg_replace('/.*/e',...) - /e does an eval() on the match
create_function()
include()
include_once()
require()
require_once()
$_GET['func_name']($_GET['argument']);
$func = new ReflectionFunction($_GET['func_name']); $func->invoke(); or $func->invokeArgs(array());
List of functions which accept callbacks
These functions accept a string parameter which could be used to call a function of the attacker's choice. Depending on the function the attacker may or may not have the ability to pass a parameter. In that case an Information Disclosure function like phpinfo() could be used.
Function => Position of callback arguments
'ob_start' => 0,
'array_diff_uassoc' => -1,
'array_diff_ukey' => -1,
'array_filter' => 1,
'array_intersect_uassoc' => -1,
'array_intersect_ukey' => -1,
'array_map' => 0,
'array_reduce' => 1,
'array_udiff_assoc' => -1,
'array_udiff_uassoc' => array(-1, -2),
'array_udiff' => -1,
'array_uintersect_assoc' => -1,
'array_uintersect_uassoc' => array(-1, -2),
'array_uintersect' => -1,
'array_walk_recursive' => 1,
'array_walk' => 1,
'assert_options' => 1,
'uasort' => 1,
'uksort' => 1,
'usort' => 1,
'preg_replace_callback' => 1,
'spl_autoload_register' => 0,
'iterator_apply' => 1,
'call_user_func' => 0,
'call_user_func_array' => 0,
'register_shutdown_function' => 0,
'register_tick_function' => 0,
'set_error_handler' => 0,
'set_exception_handler' => 0,
'session_set_save_handler' => array(0, 1, 2, 3, 4, 5),
'sqlite_create_aggregate' => array(2, 3),
'sqlite_create_function' => 2,
Information Disclosure
Most of these function calls are not sinks. But rather it maybe a vulnerability if any of the data returned is viewable to an attacker. If an attacker can see phpinfo() it is definitely a vulnerability.
phpinfo
posix_mkfifo
posix_getlogin
posix_ttyname
getenv
get_current_user
proc_get_status
get_cfg_var
disk_free_space
disk_total_space
diskfreespace
getcwd
getlastmo
getmygid
getmyinode
getmypid
getmyuid
Other
extract - Opens the door for register_globals attacks (see study in scarlet).
parse_str - works like extract if only one argument is given.
putenv
ini_set
mail - has CRLF injection in the 3rd parameter, opens the door for spam.
header - on old systems CRLF injection could be used for xss or other purposes, now it is still a problem if they do a header("location: ..."); and they do not die();. The script keeps executing after a call to header(), and will still print output normally. This is nasty if you are trying to protect an administrative area.
proc_nice
proc_terminate
proc_close
pfsockopen
fsockopen
apache_child_terminate
posix_kill
posix_mkfifo
posix_setpgid
posix_setsid
posix_setuid
Filesystem Functions
According to RATS all filesystem functions in php are nasty. Some of these don't seem very useful to the attacker. Others are more useful than you might think. For instance if allow_url_fopen=On then a url can be used as a file path, so a call to copy($_GET['s'], $_GET['d']); can be used to upload a PHP script anywhere on the system.
Also if a site is vulnerable to a request send via GET everyone of those file system functions can be abused to channel and attack to another host through your server.
// open filesystem handler
fopen
tmpfile
bzopen
gzopen
SplFileObject->__construct
// write to filesystem (partially in combination with reading)
chgrp
chmod
chown
copy
file_put_contents
lchgrp
lchown
link
mkdir
move_uploaded_file
rename
rmdir
symlink
tempnam
touch
unlink
imagepng - 2nd parameter is a path.
imagewbmp - 2nd parameter is a path.
image2wbmp - 2nd parameter is a path.
imagejpeg - 2nd parameter is a path.
imagexbm - 2nd parameter is a path.
imagegif - 2nd parameter is a path.
imagegd - 2nd parameter is a path.
imagegd2 - 2nd parameter is a path.
iptcembed
ftp_get
ftp_nb_get
// read from filesystem
file_exists
file_get_contents
file
fileatime
filectime
filegroup
fileinode
filemtime
fileowner
fileperms
filesize
filetype
glob
is_dir
is_executable
is_file
is_link
is_readable
is_uploaded_file
is_writable
is_writeable
linkinfo
lstat
parse_ini_file
pathinfo
readfile
readlink
realpath
stat
gzfile
readgzfile
getimagesize
imagecreatefromgif
imagecreatefromjpeg
imagecreatefrompng
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromxpm
ftp_put
ftp_nb_put
exif_read_data
read_exif_data
exif_thumbnail
exif_imagetype
hash_file
hash_hmac_file
hash_update_file
md5_file
sha1_file
highlight_file
show_source
php_strip_whitespace
get_meta_tags
You'd have to scan for include($tmp) and require(HTTP_REFERER) and *_once as well. If an exploit script can write to a temporary file, it could just include that later. Basically a two-step eval.
And it's even possible to hide remote code with workarounds like:
include("data:text/plain;base64,$_GET[code]");
Also, if your webserver has already been compromised you will not always see unencoded evil. Often the exploit shell is gzip-encoded. Think of include("zlib:script2.png.gz"); No eval here, still same effect.
This is not an answer per se, but here's something interesting:
$y = str_replace('z', 'e', 'zxzc');
$y("malicious code");
In the same spirit, call_user_func_array() can be used to execute obfuscated functions.
I'm surprised no one has mentioned echo and print as points of security exploitation.
Cross-Site Scripting (XSS) is a serious security exploit, because it's even more common than server-side code execution exploits.
i'd particularly want to add unserialize() to this list. It has had a long history of various vulnerabilities including arbitrary code execution, denial of service and memory information leakage. It should never be called on user-supplied data. Many of these vuls have been fixed in releases over the last dew years, but it still retains a couple of nasty vuls at the current time of writing.
For other information about dodgy php functions/usage look around the Hardened PHP Project and its advisories. Also the recent Month of PHP Security and 2007's Month of PHP Bugs projects
Also note that, by design, unserializing an object will cause the constructor and destructor functions to execute; another reason not to call it on user-supplied data.
My VPS is set to disable the following functions:
root#vps [~]# grep disable_functions /usr/local/lib/php.ini
disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid
PHP has enough potentially destructible functions that your list might be too big to grep for. For example, PHP has chmod and chown, which could be used to simply deactivate a website.
EDIT: Perhaps you may want to build a bash script that searches for a file for an array of functions grouped by danger (functions that are bad, functions that are worse, functions that should never be used), and then calculate the relativity of danger that the file imposes into a percentage. Then output this to a tree of the directory with the percentages tagged next to each file, if greater than a threshold of say, 30% danger.
Also be aware of the class of "interruption vulnerabilities" that allow arbitrary memory locations to be read and written!
These affect functions such as trim(), rtrim(), ltrim(), explode(), strchr(), strstr(), substr(), chunk_split(), strtok(), addcslashes(), str_repeat() and more. This is largely, but not exclusively, due to the call-time pass-by-reference feature of the language that has been deprecated for 10 years but not disabled.
Fore more info, see Stefan Esser’s talk about interruption vulnerabilities and other lower-level PHP issues at BlackHat USA 2009 Slides Paper
This paper/presentation also shows how dl() can be used to execute arbitrary system code.
Plattform-specific, but also theoretical exec vectors:
dotnet_load()
new COM("WScript.Shell")
new Java("java.lang.Runtime")
event_new() - very eventually
And there are many more disguising methods:
proc_open is an alias for popen
call_user_func_array("exE".chr(99), array("/usr/bin/damage", "--all"));
file_put_contents("/cgi-bin/nextinvocation.cgi") && chmod(...)
PharData::setDefaultStub - some more work to examine code in .phar files
runkit_function_rename("exec", "innocent_name") or APD rename_function
Apart from the eval language construct there is another function which allows arbitrary code execution: assert
assert('ex' . 'ec("kill --bill")');
One source of interesting exploits has not been mentioned. PHP allows strings to have 0x00 bytes in them. Underlying (libc) functions treat this as the end of a string.
This allows for situations where (poorly implemented) sanity-checking in PHP can be fooled, e.g. in a situation like:
/// note: proof of principle code, don't use
$include = $_GET['file'];
if ( preg_match("/\\.php$/",$include) ) include($include);
This might include any file - not just those ending in .php - by calling script.php?file=somefile%00.php
So any function that will not obey PHP's string length may lead to some vulnerability.
What about dangerous syntactic elements?
The "variable variable" ($$var) will find a variable in the current scope by the name of $var. If used wrong, the remote user can modify or read any variable in the current scope. Basically a weaker eval.
Ex: you write some code $$uservar = 1;, then the remote user sets $uservar to "admin", causing $admin to be set to 1 in the current scope.
I guess you won't be able to really find all possible exploits by parsing your source files.
also if there are really great lists provided in here, you can miss a function which can be exploitet
there still could be "hidden" evil code like this
$myEvilRegex = base64_decode('Ly4qL2U=');
preg_replace($myEvilRegex, $_POST['code']);
you could now say, i simply extend my script to also match this
but then you will have that mayn "possibly evil code" which additionally is out of it's context
so to be (pseudo-)secure, you should really write good code and read all existing code yourself
Backtick Operator Backtick on php manual
I know move_uploaded_file has been mentioned, but file uploading in general is very dangerous. Just the presence of $_FILES should raise some concern.
It's quite possible to embed PHP code into any type of file. Images can be especially vulnerable with text comments. The problem is particularly troublesome if the code accepts the extension found within the $_FILES data as-is.
For example, a user could upload a valid PNG file with embedded PHP code as "foo.php". If the script is particularly naive, it may actually copy the file as "/uploads/foo.php". If the server is configured to allow script execution in user upload directories (often the case, and a terrible oversight), then you instantly can run any arbitrary PHP code. (Even if the image is saved as .png, it might be possible to get the code to execute via other security flaws.)
A (non-exhaustive) list of things to check on uploads:
Make sure to analyze the contents to make sure the upload is the type it claims to be
Save the file with a known, safe file extension that will not ever be executed
Make sure PHP (and any other code execution) is disabled in user upload directories
Let's add pcntl_signal and pcntl_alarm to the list.
With the help of those functions you can work around any set_time_limit restriction created int the php.ini or in the script.
This script for example will run for 10 seconds despite of set_time_limit(1);
(Credit goes to Sebastian Bergmanns tweet and gist:
<?php
declare(ticks = 1);
set_time_limit(1);
function foo() {
for (;;) {}
}
class Invoker_TimeoutException extends RuntimeException {}
class Invoker
{
public function invoke($callable, $timeout)
{
pcntl_signal(SIGALRM, function() { throw new Invoker_TimeoutException; }, TRUE);
pcntl_alarm($timeout);
call_user_func($callable);
}
}
try {
$invoker = new Invoker;
$invoker->invoke('foo', 1);
} catch (Exception $e) {
sleep(10);
echo "Still running despite of the timelimit";
}
There are loads of PHP exploits which can be disabled by settings in the PHP.ini file. Obvious example is register_globals, but depending on settings it may also be possible to include or open files from remote machines via HTTP, which can be exploited if a program uses variable filenames for any of its include() or file handling functions.
PHP also allows variable function calling by adding () to the end of a variable name -- eg $myvariable(); will call the function name specified by the variable. This is exploitable; eg if an attacker can get the variable to contain the word 'eval', and can control the parameter, then he can do anything he wants, even though the program doesn't actually contain the eval() function.
These functions can also have some nasty effects.
str_repeat()
unserialize()
register_tick_function()
register_shutdown_function()
The first two can exhaust all the available memory and the latter keep the exhaustion going...
There was some discussion of this on security.stackexchange.com recently
functions that can be used for arbitrary code execution
Well that reduces the scope a little - but since 'print' can be used to inject javascript (and therefore steal sessions etc) its still somewhat arbitrary.
isn't to list functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have a grep-able list
That's a sensible approach.
Do consider writing your own parser though - very soon you're going to find a grep based approach getting out of control (awk would be a bit better). Pretty soon you're also going to start wishing you'd implemented a whitelist too!
In addition to the obvious ones, I'd recommend flagging up anything which does an include with an argument of anything other than a string literal. Watch out for __autoload() too.
I fear my answer might be a bit too negative, but...
IMHO, every single function and method out there can be used for nefarious purposes. Think of it as a trickle-down effect of nefariousness: a variable gets assigned to a user or remote input, the variable is used in a function, the function return value used in a class property, the class property used in a file function, and so forth. Remember: a forged IP address or a man-in-the-middle attack can exploit your entire website.
Your best bet is to trace from beginning to end any possible user or remote input, starting with $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file) (if allow_url_fopen is on), all other functions/classes dealing with remote files, etc. You programatically build a stack-trace profile of each user- or remote-supplied value. This can be done programatically by getting all repeat instances of the assigned variable and functions or methods it's used in, then recursively compiling a list of all occurrences of those functions/methods, and so on. Examine it to ensure it first goes through the proper filtering and validating functions relative to all other functions it touches. This is of course a manual examination, otherwise you'll have a total number of case switches equal to the number of functions and methods in PHP (including user defined).
Alternatively for handling only user input, have a static controller class initialized at the beginning of all scripts which 1) validates and stores all user-supplied input values against a white-list of allowed purposes; 2) wipes that input source (ie $_SERVER = null). You can see where this gets a little Naziesque.
Here is a list of functions my provider disables for security purposes:
exec
dl
show_source
apache_note
apache_setenv
closelog
debugger_off
debugger_on
define_syslog_variables
escapeshellarg
escapeshellcmd
ini_restore
openlog
passthru
pclose
pcntl_exec
popen
proc_close
proc_get_status
proc_nice
proc_open
proc_terminate
shell_exec
syslog
system
url_exec
Most of attacks in the code use multiple access sources, or multiple steps to execute themselves. I would search not only for a code, or method having malicious code, but all methods, function executing or calling it. The best security would also include encoding and validating form data as it comes in and out.
Watch also out from defining system variables, they can afterwards be called from any function or method in the code.
Several buffer overflows were discovered using 4bit
characters functions that interpret text.
htmlentities()
htmlspecialchars()
were at the top, a good defence is to use
mb_convert_encoding() to convert to single
encoding prior to interpretation.
You can find a continuously updated list of sensitive sinks (exploitable php functions) and their parameters in RIPS /config/sinks.php, a static source code analyser for vulnerabilities in PHP applications that also detects PHP backdoors.
First off, this is an exact duplicate of these four questions:
Highlight the difference between two strings in PHP
JavaScript based diff utility
How to do text DIFF using PHP?
Calculate text diffs in PHP
It seems as though times have changed since these questions were first asked and I am wondering what is a good tool now-a-days for this sort of comparison? I have looked at (additionally to those questions):
https://github.com/nuxodin/diff_match_patch-php
http://pear.php.net/package/Text_Diff
https://github.com/paulgb/simplediff/blob/5bfe1d2a8f967c7901ace50f04ac2d9308ed3169/simplediff.php
http://www.raymondhill.net/finediff/viewdiff-ex.php
But all of the ones I get are either unmantained now or seem a little dodgy in that they are not used that much (and some even hint that they are not very performant) and the PEAR one worries me. I hate to install PEAR for one little module not only that but it seems like throwing a brick through my own window to install it for such a small module in comparison to PEAR in general not only that but the module has been superseded and placed on a different channel (dunno why?). I would use the PEAR version if it is my only choice but I want to use the upto date package.
Does anyone know of a well used and currently maintained or built in function (even if it is a PHP extension) text diff for PHP and/or JavaScript (JQuery as well)?
Ok so it has been a while.
I actually decided to look around at what other people use and stumbled upon what Yii ( http://www.yiiframework.com ) uses.
They actually use the PEAR module for their text_diff and they use it in its new form on the horde channel. It seems that text_diff is now a horde project but you can just as easily integrate a version of it into your application and that is what Yii does by default (it comes pre-bundled with a version of it).
So I searched around a bit to find out how they used it and how to get into it and I came across:
public function actionDiff()
{
Yii::import('gii.components.TextDiff');
$model=$this->prepare();
if(isset($_GET['id']) && isset($model->files[$_GET['id']]))
{
$file=$model->files[$_GET['id']];
if(!in_array($file->type,array('php', 'txt','js','css')))
$diff=false;
elseif($file->operation===CCodeFile::OP_OVERWRITE)
$diff=TextDiff::compare(file_get_contents($file->path), $file->content);
else
$diff='';
$this->renderPartial('/common/diff',array(
'file'=>$file,
'diff'=>$diff,
));
}
else
throw new CHttpException(404,'Unable to find the code you requested.');
}
In CCodeGenerator for their Gii module ( http://www.yiiframework.com/doc/api/1.1/CCodeGenerator/ ). The important part is where they actually hook into the PEAR module:
$diff=TextDiff::compare(file_get_contents($file->path), $file->content);
By reading in the contents of two files which produces a diffed output.
Originally I did not want to use PEAR because of the bloat but this module is quite slim for a fully featured text_diff so I have decided to go with this. Not only that but, at the moment, it is the only text_diff module that has truly worked for me so I am keeping with the best, even if the best is quite memory hungry.
Have you tried one of Philippe's two solutions on this thread?
Quoted here:
In PHP. array_diff compares the first against the second array and
returns the difference.
$a1 = str_split('abcdefghijklmnop');
$a2 = str_split('abcdefghi');
echo join('', array_diff($a1, $a2)); // jklmnop
This will work as well:
$s1 = 'abcdefghijklmnop';
$s2 = 'abcdefghi';
echo str_replace(str_split($s2), '', $s1); // jklmnop
This could handle $s2 = 'ghiabcdef'; as well because str_replace() is fed with an
array, not a string.
Is there a way to remove function alias in PHP?
I can rename my function but it would be nice to use name "fetch".
Problem:
I just tested the following code and it appears to work for me, but perhaps it is because I don't have the mysqli library installed. I would test it because it might be more contextual than your IDE will have you believe. It seems to be a method for mysqli, but it might not be a global function.
<?php
function fetch(){
echo 'Hello world!';
}
fetch();
No.
(Short of recompiling the PHP binary)
This is more of a function of the IDE than the actual language... Some IDEs may give you that ability... I don't even know if recompiling the PHP binary (as Alan Storm suggested) would help since sometimes the stuff is hardcoded into the IDE / use the PHP docs online
For completeness sake: Normally, no, this can not be done. However: this can be done using a PECL extension called "runkit".
Runkit is described as "For all those things you probably shouldn't have been doing anyway", and allows you to basically tear out the innards of PHP from within PHP itself. Replacing built-in functions, undefining constants, unloading classes - suddenly everything is possible. And you should really question what you are doing if you ever feel you need it - odds are what you are doing violates some principles that are there for very good reasons, you just don't know them yet. I've never found a situation where using Runkit was a genuinely Good Idea.
Oh, in order to remove built-in functions you'll specifically need to enable this capability in your php.ini
(have fun!)
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I'm trying to build a list of functions that can be used for arbitrary code execution. The purpose isn't to list functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have a grep-able list of red-flag keywords handy when searching a compromised server for back-doors.
The idea is that if you want to build a multi-purpose malicious PHP script -- such as a "web shell" script like c99 or r57 -- you're going to have to use one or more of a relatively small set of functions somewhere in the file in order to allow the user to execute arbitrary code. Searching for those those functions helps you more quickly narrow down a haystack of tens-of-thousands of PHP files to a relatively small set of scripts that require closer examination.
Clearly, for example, any of the following would be considered malicious (or terrible coding):
<? eval($_GET['cmd']); ?>
<? system($_GET['cmd']); ?>
<? preg_replace('/.*/e',$_POST['code']); ?>
and so forth.
Searching through a compromised website the other day, I didn't notice a piece of malicious code because I didn't realize preg_replace could be made dangerous by the use of the /e flag (which, seriously? Why is that even there?). Are there any others that I missed?
Here's my list so far:
Shell Execute
system
exec
popen
backtick operator
pcntl_exec
PHP Execute
eval
preg_replace (with /e modifier)
create_function
include[_once] / require[_once] (see mario's answer for exploit details)
It might also be useful to have a list of functions that are capable of modifying files, but I imagine 99% of the time exploit code will contain at least one of the functions above. But if you have a list of all the functions capable of editing or outputting files, post it and I'll include it here. (And I'm not counting mysql_execute, since that's part of another class of exploit.)
To build this list I used 2 sources. A Study In Scarlet and RATS. I have also added some of my own to the mix and people on this thread have helped out.
Edit: After posting this list I contacted the founder of RIPS and as of now this tools searches PHP code for the use of every function in this list.
Most of these function calls are classified as Sinks. When a tainted variable (like $_REQUEST) is passed to a sink function, then you have a vulnerability. Programs like RATS and RIPS use grep like functionality to identify all sinks in an application. This means that programmers should take extra care when using these functions, but if they where all banned then you wouldn't be able to get much done.
"With great power comes great responsibility."
--Stan Lee
Command Execution
exec - Returns last line of commands output
passthru - Passes commands output directly to the browser
system - Passes commands output directly to the browser and returns last line
shell_exec - Returns commands output
`` (backticks) - Same as shell_exec()
popen - Opens read or write pipe to process of a command
proc_open - Similar to popen() but greater degree of control
pcntl_exec - Executes a program
PHP Code Execution
Apart from eval there are other ways to execute PHP code: include/require can be used for remote code execution in the form of Local File Include and Remote File Include vulnerabilities.
eval()
assert() - identical to eval()
preg_replace('/.*/e',...) - /e does an eval() on the match
create_function()
include()
include_once()
require()
require_once()
$_GET['func_name']($_GET['argument']);
$func = new ReflectionFunction($_GET['func_name']); $func->invoke(); or $func->invokeArgs(array());
List of functions which accept callbacks
These functions accept a string parameter which could be used to call a function of the attacker's choice. Depending on the function the attacker may or may not have the ability to pass a parameter. In that case an Information Disclosure function like phpinfo() could be used.
Function => Position of callback arguments
'ob_start' => 0,
'array_diff_uassoc' => -1,
'array_diff_ukey' => -1,
'array_filter' => 1,
'array_intersect_uassoc' => -1,
'array_intersect_ukey' => -1,
'array_map' => 0,
'array_reduce' => 1,
'array_udiff_assoc' => -1,
'array_udiff_uassoc' => array(-1, -2),
'array_udiff' => -1,
'array_uintersect_assoc' => -1,
'array_uintersect_uassoc' => array(-1, -2),
'array_uintersect' => -1,
'array_walk_recursive' => 1,
'array_walk' => 1,
'assert_options' => 1,
'uasort' => 1,
'uksort' => 1,
'usort' => 1,
'preg_replace_callback' => 1,
'spl_autoload_register' => 0,
'iterator_apply' => 1,
'call_user_func' => 0,
'call_user_func_array' => 0,
'register_shutdown_function' => 0,
'register_tick_function' => 0,
'set_error_handler' => 0,
'set_exception_handler' => 0,
'session_set_save_handler' => array(0, 1, 2, 3, 4, 5),
'sqlite_create_aggregate' => array(2, 3),
'sqlite_create_function' => 2,
Information Disclosure
Most of these function calls are not sinks. But rather it maybe a vulnerability if any of the data returned is viewable to an attacker. If an attacker can see phpinfo() it is definitely a vulnerability.
phpinfo
posix_mkfifo
posix_getlogin
posix_ttyname
getenv
get_current_user
proc_get_status
get_cfg_var
disk_free_space
disk_total_space
diskfreespace
getcwd
getlastmo
getmygid
getmyinode
getmypid
getmyuid
Other
extract - Opens the door for register_globals attacks (see study in scarlet).
parse_str - works like extract if only one argument is given.
putenv
ini_set
mail - has CRLF injection in the 3rd parameter, opens the door for spam.
header - on old systems CRLF injection could be used for xss or other purposes, now it is still a problem if they do a header("location: ..."); and they do not die();. The script keeps executing after a call to header(), and will still print output normally. This is nasty if you are trying to protect an administrative area.
proc_nice
proc_terminate
proc_close
pfsockopen
fsockopen
apache_child_terminate
posix_kill
posix_mkfifo
posix_setpgid
posix_setsid
posix_setuid
Filesystem Functions
According to RATS all filesystem functions in php are nasty. Some of these don't seem very useful to the attacker. Others are more useful than you might think. For instance if allow_url_fopen=On then a url can be used as a file path, so a call to copy($_GET['s'], $_GET['d']); can be used to upload a PHP script anywhere on the system.
Also if a site is vulnerable to a request send via GET everyone of those file system functions can be abused to channel and attack to another host through your server.
// open filesystem handler
fopen
tmpfile
bzopen
gzopen
SplFileObject->__construct
// write to filesystem (partially in combination with reading)
chgrp
chmod
chown
copy
file_put_contents
lchgrp
lchown
link
mkdir
move_uploaded_file
rename
rmdir
symlink
tempnam
touch
unlink
imagepng - 2nd parameter is a path.
imagewbmp - 2nd parameter is a path.
image2wbmp - 2nd parameter is a path.
imagejpeg - 2nd parameter is a path.
imagexbm - 2nd parameter is a path.
imagegif - 2nd parameter is a path.
imagegd - 2nd parameter is a path.
imagegd2 - 2nd parameter is a path.
iptcembed
ftp_get
ftp_nb_get
// read from filesystem
file_exists
file_get_contents
file
fileatime
filectime
filegroup
fileinode
filemtime
fileowner
fileperms
filesize
filetype
glob
is_dir
is_executable
is_file
is_link
is_readable
is_uploaded_file
is_writable
is_writeable
linkinfo
lstat
parse_ini_file
pathinfo
readfile
readlink
realpath
stat
gzfile
readgzfile
getimagesize
imagecreatefromgif
imagecreatefromjpeg
imagecreatefrompng
imagecreatefromwbmp
imagecreatefromxbm
imagecreatefromxpm
ftp_put
ftp_nb_put
exif_read_data
read_exif_data
exif_thumbnail
exif_imagetype
hash_file
hash_hmac_file
hash_update_file
md5_file
sha1_file
highlight_file
show_source
php_strip_whitespace
get_meta_tags
You'd have to scan for include($tmp) and require(HTTP_REFERER) and *_once as well. If an exploit script can write to a temporary file, it could just include that later. Basically a two-step eval.
And it's even possible to hide remote code with workarounds like:
include("data:text/plain;base64,$_GET[code]");
Also, if your webserver has already been compromised you will not always see unencoded evil. Often the exploit shell is gzip-encoded. Think of include("zlib:script2.png.gz"); No eval here, still same effect.
This is not an answer per se, but here's something interesting:
$y = str_replace('z', 'e', 'zxzc');
$y("malicious code");
In the same spirit, call_user_func_array() can be used to execute obfuscated functions.
I'm surprised no one has mentioned echo and print as points of security exploitation.
Cross-Site Scripting (XSS) is a serious security exploit, because it's even more common than server-side code execution exploits.
i'd particularly want to add unserialize() to this list. It has had a long history of various vulnerabilities including arbitrary code execution, denial of service and memory information leakage. It should never be called on user-supplied data. Many of these vuls have been fixed in releases over the last dew years, but it still retains a couple of nasty vuls at the current time of writing.
For other information about dodgy php functions/usage look around the Hardened PHP Project and its advisories. Also the recent Month of PHP Security and 2007's Month of PHP Bugs projects
Also note that, by design, unserializing an object will cause the constructor and destructor functions to execute; another reason not to call it on user-supplied data.
My VPS is set to disable the following functions:
root#vps [~]# grep disable_functions /usr/local/lib/php.ini
disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid
PHP has enough potentially destructible functions that your list might be too big to grep for. For example, PHP has chmod and chown, which could be used to simply deactivate a website.
EDIT: Perhaps you may want to build a bash script that searches for a file for an array of functions grouped by danger (functions that are bad, functions that are worse, functions that should never be used), and then calculate the relativity of danger that the file imposes into a percentage. Then output this to a tree of the directory with the percentages tagged next to each file, if greater than a threshold of say, 30% danger.
Also be aware of the class of "interruption vulnerabilities" that allow arbitrary memory locations to be read and written!
These affect functions such as trim(), rtrim(), ltrim(), explode(), strchr(), strstr(), substr(), chunk_split(), strtok(), addcslashes(), str_repeat() and more. This is largely, but not exclusively, due to the call-time pass-by-reference feature of the language that has been deprecated for 10 years but not disabled.
Fore more info, see Stefan Esser’s talk about interruption vulnerabilities and other lower-level PHP issues at BlackHat USA 2009 Slides Paper
This paper/presentation also shows how dl() can be used to execute arbitrary system code.
Plattform-specific, but also theoretical exec vectors:
dotnet_load()
new COM("WScript.Shell")
new Java("java.lang.Runtime")
event_new() - very eventually
And there are many more disguising methods:
proc_open is an alias for popen
call_user_func_array("exE".chr(99), array("/usr/bin/damage", "--all"));
file_put_contents("/cgi-bin/nextinvocation.cgi") && chmod(...)
PharData::setDefaultStub - some more work to examine code in .phar files
runkit_function_rename("exec", "innocent_name") or APD rename_function
Apart from the eval language construct there is another function which allows arbitrary code execution: assert
assert('ex' . 'ec("kill --bill")');
One source of interesting exploits has not been mentioned. PHP allows strings to have 0x00 bytes in them. Underlying (libc) functions treat this as the end of a string.
This allows for situations where (poorly implemented) sanity-checking in PHP can be fooled, e.g. in a situation like:
/// note: proof of principle code, don't use
$include = $_GET['file'];
if ( preg_match("/\\.php$/",$include) ) include($include);
This might include any file - not just those ending in .php - by calling script.php?file=somefile%00.php
So any function that will not obey PHP's string length may lead to some vulnerability.
What about dangerous syntactic elements?
The "variable variable" ($$var) will find a variable in the current scope by the name of $var. If used wrong, the remote user can modify or read any variable in the current scope. Basically a weaker eval.
Ex: you write some code $$uservar = 1;, then the remote user sets $uservar to "admin", causing $admin to be set to 1 in the current scope.
I guess you won't be able to really find all possible exploits by parsing your source files.
also if there are really great lists provided in here, you can miss a function which can be exploitet
there still could be "hidden" evil code like this
$myEvilRegex = base64_decode('Ly4qL2U=');
preg_replace($myEvilRegex, $_POST['code']);
you could now say, i simply extend my script to also match this
but then you will have that mayn "possibly evil code" which additionally is out of it's context
so to be (pseudo-)secure, you should really write good code and read all existing code yourself
Backtick Operator Backtick on php manual
I know move_uploaded_file has been mentioned, but file uploading in general is very dangerous. Just the presence of $_FILES should raise some concern.
It's quite possible to embed PHP code into any type of file. Images can be especially vulnerable with text comments. The problem is particularly troublesome if the code accepts the extension found within the $_FILES data as-is.
For example, a user could upload a valid PNG file with embedded PHP code as "foo.php". If the script is particularly naive, it may actually copy the file as "/uploads/foo.php". If the server is configured to allow script execution in user upload directories (often the case, and a terrible oversight), then you instantly can run any arbitrary PHP code. (Even if the image is saved as .png, it might be possible to get the code to execute via other security flaws.)
A (non-exhaustive) list of things to check on uploads:
Make sure to analyze the contents to make sure the upload is the type it claims to be
Save the file with a known, safe file extension that will not ever be executed
Make sure PHP (and any other code execution) is disabled in user upload directories
Let's add pcntl_signal and pcntl_alarm to the list.
With the help of those functions you can work around any set_time_limit restriction created int the php.ini or in the script.
This script for example will run for 10 seconds despite of set_time_limit(1);
(Credit goes to Sebastian Bergmanns tweet and gist:
<?php
declare(ticks = 1);
set_time_limit(1);
function foo() {
for (;;) {}
}
class Invoker_TimeoutException extends RuntimeException {}
class Invoker
{
public function invoke($callable, $timeout)
{
pcntl_signal(SIGALRM, function() { throw new Invoker_TimeoutException; }, TRUE);
pcntl_alarm($timeout);
call_user_func($callable);
}
}
try {
$invoker = new Invoker;
$invoker->invoke('foo', 1);
} catch (Exception $e) {
sleep(10);
echo "Still running despite of the timelimit";
}
There are loads of PHP exploits which can be disabled by settings in the PHP.ini file. Obvious example is register_globals, but depending on settings it may also be possible to include or open files from remote machines via HTTP, which can be exploited if a program uses variable filenames for any of its include() or file handling functions.
PHP also allows variable function calling by adding () to the end of a variable name -- eg $myvariable(); will call the function name specified by the variable. This is exploitable; eg if an attacker can get the variable to contain the word 'eval', and can control the parameter, then he can do anything he wants, even though the program doesn't actually contain the eval() function.
These functions can also have some nasty effects.
str_repeat()
unserialize()
register_tick_function()
register_shutdown_function()
The first two can exhaust all the available memory and the latter keep the exhaustion going...
There was some discussion of this on security.stackexchange.com recently
functions that can be used for arbitrary code execution
Well that reduces the scope a little - but since 'print' can be used to inject javascript (and therefore steal sessions etc) its still somewhat arbitrary.
isn't to list functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have a grep-able list
That's a sensible approach.
Do consider writing your own parser though - very soon you're going to find a grep based approach getting out of control (awk would be a bit better). Pretty soon you're also going to start wishing you'd implemented a whitelist too!
In addition to the obvious ones, I'd recommend flagging up anything which does an include with an argument of anything other than a string literal. Watch out for __autoload() too.
I fear my answer might be a bit too negative, but...
IMHO, every single function and method out there can be used for nefarious purposes. Think of it as a trickle-down effect of nefariousness: a variable gets assigned to a user or remote input, the variable is used in a function, the function return value used in a class property, the class property used in a file function, and so forth. Remember: a forged IP address or a man-in-the-middle attack can exploit your entire website.
Your best bet is to trace from beginning to end any possible user or remote input, starting with $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file) (if allow_url_fopen is on), all other functions/classes dealing with remote files, etc. You programatically build a stack-trace profile of each user- or remote-supplied value. This can be done programatically by getting all repeat instances of the assigned variable and functions or methods it's used in, then recursively compiling a list of all occurrences of those functions/methods, and so on. Examine it to ensure it first goes through the proper filtering and validating functions relative to all other functions it touches. This is of course a manual examination, otherwise you'll have a total number of case switches equal to the number of functions and methods in PHP (including user defined).
Alternatively for handling only user input, have a static controller class initialized at the beginning of all scripts which 1) validates and stores all user-supplied input values against a white-list of allowed purposes; 2) wipes that input source (ie $_SERVER = null). You can see where this gets a little Naziesque.
Here is a list of functions my provider disables for security purposes:
exec
dl
show_source
apache_note
apache_setenv
closelog
debugger_off
debugger_on
define_syslog_variables
escapeshellarg
escapeshellcmd
ini_restore
openlog
passthru
pclose
pcntl_exec
popen
proc_close
proc_get_status
proc_nice
proc_open
proc_terminate
shell_exec
syslog
system
url_exec
Most of attacks in the code use multiple access sources, or multiple steps to execute themselves. I would search not only for a code, or method having malicious code, but all methods, function executing or calling it. The best security would also include encoding and validating form data as it comes in and out.
Watch also out from defining system variables, they can afterwards be called from any function or method in the code.
Several buffer overflows were discovered using 4bit
characters functions that interpret text.
htmlentities()
htmlspecialchars()
were at the top, a good defence is to use
mb_convert_encoding() to convert to single
encoding prior to interpretation.
You can find a continuously updated list of sensitive sinks (exploitable php functions) and their parameters in RIPS /config/sinks.php, a static source code analyser for vulnerabilities in PHP applications that also detects PHP backdoors.