Exploitable PHP functions

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 outputpassthru       - Passes commands output directly to the browsersystem         - Passes commands output directly to the browser and returns last lineshell_exec     - Returns commands output`` (backticks) - Same as shell_exec()popen          - Opens read or write pipe to process of a commandproc_open      - Similar to popen() but greater degree of controlpcntl_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 matchcreate_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.

phpinfoposix_mkfifoposix_getloginposix_ttynamegetenvget_current_userproc_get_statusget_cfg_vardisk_free_spacedisk_total_spacediskfreespacegetcwdgetlastmogetmygidgetmyinodegetmypidgetmyuid

Other

extract - Opens the door for register_globals attacks (see study in scarlet).parse_str -  works like extract if only one argument is given.  putenvini_setmail - 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_niceproc_terminateproc_closepfsockopenfsockopenapache_child_terminateposix_killposix_mkfifoposix_setpgidposix_setsidposix_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 handlerfopentmpfilebzopengzopenSplFileObject->__construct// write to filesystem (partially in combination with reading)chgrpchmodchowncopyfile_put_contentslchgrplchownlinkmkdirmove_uploaded_filerenamermdirsymlinktempnamtouchunlinkimagepng   - 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.iptcembedftp_getftp_nb_get// read from filesystemfile_existsfile_get_contentsfilefileatimefilectimefilegroupfileinodefilemtimefileownerfilepermsfilesizefiletypeglobis_diris_executableis_fileis_linkis_readableis_uploaded_fileis_writableis_writeablelinkinfolstatparse_ini_filepathinforeadfilereadlinkrealpathstatgzfilereadgzfilegetimagesizeimagecreatefromgifimagecreatefromjpegimagecreatefrompngimagecreatefromwbmpimagecreatefromxbmimagecreatefromxpmftp_putftp_nb_putexif_read_dataread_exif_dataexif_thumbnailexif_imagetypehash_filehash_hmac_filehash_update_filemd5_filesha1_filehighlight_fileshow_sourcephp_strip_whitespaceget_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.