Fonctions PHP exploitables

277

J'essaie de construire une liste de fonctions qui peuvent être utilisées pour l'exécution de code arbitraire. Le but n'est pas de répertorier les fonctions qui devraient être mises sur liste noire ou autrement interdites. Au lieu de cela, j'aimerais avoir une grepliste des mots clés à drapeau rouge à portée de main lors de la recherche de portes dérobées sur un serveur compromis.

L'idée est que si vous voulez créer un script PHP malveillant polyvalent - comme un script "web shell" comme c99 ou r57 - vous allez devoir utiliser une ou plusieurs fonctions relativement petites quelque part dans le fichier afin de permettre à l'utilisateur d'exécuter du code arbitraire. La recherche de ces fonctions vous aide à affiner plus rapidement une meule de foin de dizaines de milliers de fichiers PHP à un ensemble relativement petit de scripts qui nécessitent un examen plus approfondi.

De toute évidence, par exemple, l'un des éléments suivants serait considéré comme malveillant (ou terrible codage):

<? eval($_GET['cmd']); ?>

<? system($_GET['cmd']); ?>

<? preg_replace('/.*/e',$_POST['code']); ?>

et ainsi de suite.

La recherche sur un site Web compromis l'autre jour, je n'ai pas remarqué un morceau de code malveillant parce que je ne savais pas que cela preg_replacepourrait être rendu dangereux par l'utilisation du /edrapeau ( ce qui, sérieusement? Pourquoi est-ce encore là ?). Y en a-t-il d'autres que j'ai ratés?

Voici ma liste jusqu'à présent:

Shell Execute

  • system
  • exec
  • popen
  • backtick operator
  • pcntl_exec

PHP Execute

  • eval
  • preg_replace(avec /emodificateur)
  • create_function
  • include[ _once] / require[ _once] ( voir la réponse de mario pour les détails de l'exploit)

Il pourrait également être utile d'avoir une liste de fonctions capables de modifier des fichiers, mais j'imagine que 99% du temps, le code d'exploitation contiendra au moins une des fonctions ci-dessus. Mais si vous avez une liste de toutes les fonctions capables d'éditer ou de sortir des fichiers, postez-la et je l'inclurai ici. (Et je ne compte pas mysql_execute, car cela fait partie d'une autre classe d'exploit.)

tylerl
la source
43
en tant que sidenote, j'aimerais voir cette liste publiée dans un avenir proche, si possible :)
yoda
16
@yoda: publié où? Je garderai la liste à jour ici, car SO est la source de toutes les connaissances.
tylerl
3
Que fait le /emodificateur?
Billy ONeal
6
@Billy: le emodificateur rend la chaîne de remplacement à évaluer en tant que code PHP.
nikc.org
1
Il faut le dire: exécuter le code dans l'expression régulière est quelque chose que Perl et peut-être Python font aussi, pas quelque chose d'exclusif à PHP. Mais je ne connais pas les détails.
Adriano Varoli Piazza

Réponses:

205

Pour construire cette liste, j'ai utilisé 2 sources. Une étude dans Scarlet et RATS . J'ai également ajouté quelques-uns des miens au mix et les gens de ce fil ont aidé.

Edit: Après avoir publié cette liste, j'ai contacté le fondateur de RIPS et à partir de maintenant, cet outil recherche dans le code PHP l'utilisation de toutes les fonctions de cette liste.

La plupart de ces appels de fonction sont classés comme récepteurs. Lorsqu'une variable contaminée (comme $ _REQUEST) est passée à une fonction puits, alors vous avez une vulnérabilité. Des programmes comme RATS et RIPS utilisent une fonctionnalité de type grep pour identifier tous les récepteurs dans une application. Cela signifie que les programmeurs doivent faire très attention lors de l'utilisation de ces fonctions, mais s'ils sont tous interdits, vous ne pourrez pas faire grand-chose.

" Une grande puissance s'accompagne d'une grande responsabilité. "

--Stan Lee

Exécution de commande

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

Exécution de code PHP

En dehors de cela, evalil existe d'autres façons d'exécuter du code PHP: include/ requirepeut être utilisé pour l'exécution de code à distance sous la forme de vulnérabilités Local File Include et Remote File Include .

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());

Liste des fonctions acceptant les rappels

Ces fonctions acceptent un paramètre de chaîne qui pourrait être utilisé pour appeler une fonction au choix de l'attaquant. Selon la fonction, l'attaquant peut ou non avoir la capacité de passer un paramètre. Dans ce cas, une Information Disclosurefonction comme phpinfo()pourrait être utilisée.

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,

Divulgation d'information

La plupart de ces appels de fonction ne sont pas des puits. Mais il s'agit plutôt d'une vulnérabilité si l'une des données renvoyées est visible pour un attaquant. Si un attaquant peut le voir, phpinfo()c'est certainement une vulnérabilité.

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

Autre

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

Fonctions du système de fichiers

Selon RATS, toutes les fonctions du système de fichiers en php sont désagréables. Certains d'entre eux ne semblent pas très utiles à l'attaquant. D'autres sont plus utiles que vous ne le pensez. Par exemple, si allow_url_fopen=Onune URL peut être utilisée comme chemin de fichier, un appel à copy($_GET['s'], $_GET['d']);peut être utilisé pour télécharger un script PHP n'importe où sur le système. De plus, si un site est vulnérable à une demande envoyée via GET, toutes ces fonctions du système de fichiers peuvent être utilisées de manière abusive pour canaliser et attaquer un autre hôte via votre serveur.

// 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
Tour
la source
37
@whatnick En fait, je ne vois pas de différence appréciable entre PHP et les autres langages d'application Web. À la fin de la journée, les programmeurs doivent pouvoir eval()coder, exécuter des commandes système, accéder à une base de données et lire / écrire dans des fichiers. Ce code peut être influencé par un attaquant, ce qui est une vulnérabilité.
tour
8
Tant de fonctions interdites! Êtes-vous l'hôte de mon site Web par hasard?
Randy the Dev
2
@Andrew Dunn haha, non. Si vous interdisez toutes ces fonctions, aucune application PHP ne fonctionnera. Inclut en particulier (), require () et les fonctions du système de fichiers.
tour
2
@Rook: mes pensées exactement mais ce sont des problèmes potentiels, pas des problèmes précis. S'ils sont utilisés correctement, aucun de ceux-ci ne constitue une menace immédiate; mais s'ils peuvent être évités, ils devraient l'être.
Geekster
3
IMHO preg_matchavec epas de mal. Le manuel indique que "seul preg_replace () utilise ce modificateur; il est ignoré par les autres fonctions PCRE."
NikiC
59

Vous devez rechercher include ($ tmp) et exiger également (HTTP_REFERER) et * _once. Si un script d'exploitation peut écrire dans un fichier temporaire, il pourrait simplement l'inclure plus tard. Fondamentalement, une évaluation en deux étapes.

Et il est même possible de masquer le code à distance avec des solutions de contournement comme:

 include("data:text/plain;base64,$_GET[code]");

De plus, si votre serveur Web a déjà été compromis, vous ne verrez pas toujours le mal non codé. Souvent, le shell d'exploitation est encodé en gzip. Pensez à include("zlib:script2.png.gz");No eval ici, toujours le même effet.

mario
la source
1
Selon la façon dont PHP est configuré, include peut en fait inclure du code provenant d'URL arbitraires. Quelque chose comme " example.com/code.phps "; J'ai vu un site Web compromis qui avait été piraté en utilisant une combinaison de cette fonctionnalité et register_globals.
BlackAura
@BlackAura comment regiser_globals s'est-il adapté à l'attaque? Est-ce quelque chose qui aurait pu être retiré aussi facilement en utilisant $_GET[xyz]que par opposition à $xyz? Ou y avait-il quelque chose de plus profond?
tylerl
Je ne sais pas trop pourquoi cela a été fait de cette façon, mais le site Web a continué à faire des choses comme ceci: include ($ prefix. '/Filename.php'); Je pense que l'idée était que vous pouviez déplacer le code principal en dehors de la racine Web, en définissant la variable $ prefix dans le fichier de configuration. Si l'attaquant définit cette valeur sur quelque chose comme " example.com/code.phps ?", PHP inclura ce fichier distant à la place. Autant que je sache, un bot a réussi à s'introduire en utilisant un exploit générique. Apparemment, beaucoup d'anciens codes PHP ont fait cette erreur. Fondamentalement, ne laissez JAMAIS une valeur soumise par l'utilisateur à proximité d'une instruction include.
BlackAura
Je pense que vous pouvez généraliser cela à des inclusions qui contiennent un ":" dans le nom de fichier ... sauf que le nom de fichier peut être une variable, ce qui le rend difficile à grepsaisir. PHP - quel désastre.
tylerl
2
includene nécessite pas de parenthèses; include "…"suffit.
Gumbo
48

Ce n'est pas une réponse en soi, mais voici quelque chose d'intéressant:

$y = str_replace('z', 'e', 'zxzc');
$y("malicious code");

Dans le même esprit, call_user_func_array()peut être utilisé pour exécuter des fonctions obscurcies.

Aillyn
la source
1
Et il n'y a aucun moyen de trouver cela sans exécuter le code :( L'analyse statique n'aidera pas ici.
NikiC
15
@tylerl: ... ou toute autre langue?
dr Hannibal Lecter
@dr Hannibal Lector: même des langues compilées?
Ponkadoodle
3
@Wallacoloo: Il est encore plus facile de masquer une porte dérobée CGI de langue compilée car il n'y a pas de chaînes de texte faciles à récupérer dans un binaire.
Iiridayn
2
Bien .. J'ai essayé avec $ f = 'ev'. 'Al'; $ f ($ _ POST ['c']); mais n'a pas fonctionné car 'eval' n'est pas une fonction mais une construction spéciale comme include, echo, etc. -> intéressant que exec () ne soit pas et donc cela fonctionnerait ..
redShadow
20

Je suis surpris que personne ne l'ait mentionné echoet en printtant que points d'exploitation de la sécurité.

Le Cross-Site Scripting (XSS) est un sérieux exploit de sécurité, car il est encore plus courant que les exploits d'exécution de code côté serveur.

Bill Karwin
la source
Ce serait un vecteur qui affecte techniquement le client, pas le serveur.
damianb
@damianb: Si un site utilise Ajax et que je peux faire évaluer le javascript arbitraire dans la session de n'importe quel utilisateur, je pourrais causer beaucoup de méfaits sur le serveur.
Bill Karwin
"sur le serveur" .... aux clients connectés; cela n'affecte pas le serveur principal. Cela relève des exploits côté client, tels que le détournement de curseur, CSRF, l'injection d'en-tête, etc. C'est dangereux, oui, mais il relève entièrement d'une classification différente.
damianb
19

je voudrais en particulier ajouter unserialize () à cette liste. Il a une longue histoire de diverses vulnérabilités, notamment l'exécution de code arbitraire, le déni de service et la fuite d'informations de mémoire. Il ne doit jamais être appelé sur des données fournies par l'utilisateur. Beaucoup de ces vuls ont été corrigés dans les versions au cours des dernières années de rosée, mais il conserve encore quelques vuls désagréables au moment de la rédaction.

Pour d'autres informations sur les fonctions php douteuses / l'utilisation, regardez autour du projet PHP renforcé et ses conseils. Aussi le mois récent de PHP Security et le mois de 2007 des projets PHP Bugs

Notez également que, par conception, la désérialisation d'un objet entraînera l'exécution des fonctions constructeur et destructeur; une autre raison de ne pas l'appeler sur les données fournies par l'utilisateur.

Cheekysoft
la source
Je souhaite en savoir plus sur le problème de désérialisation. Est-ce juste un bogue dans l'implémentation, ou est-ce un défaut dans la conception (c'est-à-dire ne peut pas être corrigé)? Pouvez-vous me signaler plus d'informations sur cette question en particulier?
tylerl
Pour l'exécution de code arbitraire et la fuite d'informations sur la mémoire, consultez l'avis de Stefan sur php-security.org/2010/06/25/…
Cheekysoft
La récente version 5.2.14 corrige une autre vulnérabilité d'exécution de code arbitraire dans unserialize () cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2225 php.net/ChangeLog-5.php#5.2. 14
Cheekysoft
17

Mon VPS est configuré pour désactiver les fonctions suivantes:

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 a suffisamment de fonctions potentiellement destructibles pour que votre liste soit trop grande pour être utilisée. Par exemple, PHP a chmod et chown, qui pourraient être utilisés pour désactiver simplement un site Web.

EDIT: vous pouvez peut-être créer un script bash qui recherche un fichier pour un tableau de fonctions regroupées par danger (fonctions qui sont mauvaises, fonctions qui sont pires, fonctions qui ne devraient jamais être utilisées), puis calculer la relativité du danger que le fichier impose en pourcentage. Ensuite, affichez-le dans une arborescence du répertoire avec les pourcentages balisés à côté de chaque fichier, s'il est supérieur à un seuil de 30% de danger.

Josh
la source
Vous pouvez définir le drapeau "--disable-posix" au moment de la compilation et supprimer toutes ces fonctions posix de disable_functions.
The Pixel Developer
15

Soyez également conscient de la classe des "vulnérabilités d'interruption" qui permettent la lecture et l'écriture d'emplacements de mémoire arbitraires!

Ceux-ci affectent des fonctions telles que trim (), rtrim (), ltrim (), explode (), strchr (), strstr (), substr (), chunk_split (), strtok (), addcslashes (), str_repeat () et plus encore . Ceci est en grande partie, mais pas exclusivement, dû à la fonction de passage par référence du temps d'appel de la langue qui est déconseillée depuis 10 ans mais non désactivée.

Pour plus d'informations, consultez le discours de Stefan Esser sur les vulnérabilités d'interruption et d'autres problèmes PHP de niveau inférieur lors du BlackHat USA 2009 Slides Paper

Cet article / présentation montre également comment dl () peut être utilisé pour exécuter du code système arbitraire.

Cheekysoft
la source
1
Aie. Eh bien, je pensais vraiment que PHP était quelque peu sécurisé avant de jeter un œil à ces diapositives ...
NikiC
14

Des vecteurs d'exécution spécifiques à la plate-forme, mais aussi théoriques:

  • dotnet_load ()
  • nouveau COM ("WScript.Shell")
  • nouveau Java ("java.lang.Runtime")
  • event_new () - très éventuellement

Et il existe de nombreuses autres méthodes de déguisement:

  • proc_open est un alias pour popen
  • call_user_func_array ("exE" .chr (99), array ("/ usr / bin / damage", "--all"));
  • file_put_contents ("/ cgi-bin / nextinvocation.cgi") && chmod (...)
  • PharData :: setDefaultStub - un peu plus de travail pour examiner le code dans les fichiers .phar
  • runkit_function_rename ("exec", "innocent_name") ou APD rename_function
mario
la source
également call_user_func () dans cette deuxième liste
Cheekysoft
1
Une réponse suffit;) Vous devez simplement l'ajouter à la précédente.
Justin Johnson
13

Outre la evalconstruction du langage, il existe une autre fonction qui permet l'exécution de code arbitraire:assert

assert('ex' . 'ec("kill --bill")');
NikiC
la source
10

Une source d'exploits intéressants n'a pas été mentionnée. PHP permet aux chaînes de 0x00contenir des octets. Les fonctions sous-jacentes (libc) traitent cela comme la fin d'une chaîne.

Cela permet des situations où (mal implémenté) la vérification de l'intégrité en PHP peut être dupe, par exemple dans une situation comme:

/// note: proof of principle code, don't use
$include = $_GET['file'];
if ( preg_match("/\\.php$/",$include) ) include($include);

Cela peut inclure n'importe quel fichier - pas seulement ceux se terminant par .php- en appelantscript.php?file=somefile%00.php

Ainsi, toute fonction qui n'obéira pas à la longueur de chaîne de PHP peut entraîner une certaine vulnérabilité.

mvds
la source
Les chemins de fichiers avec des valeurs nulles ne seront plus autorisés dans les versions 5.4 et 5.3.
StasM
@stasM C'est l'une des meilleures choses que j'ai entendu parler de PHP depuis un moment. Merci d'avoir partagé.
William
9

Qu'en est-il des éléments syntaxiques dangereux?

La " variable variable " ( $$var) trouvera une variable dans la portée actuelle du nom de $ var. En cas d'utilisation incorrecte, l'utilisateur distant peut modifier ou lire n'importe quelle variable dans la portée actuelle. Fondamentalement, un plus faible eval.

Ex: vous écrivez du code $$uservar = 1;, puis l'utilisateur distant se positionne $uservarsur "admin", ce $adminqui entraîne sa définition 1dans la portée actuelle.

L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
la source
Je vois ce que vous voulez dire, mais cela ressemble à une classe d'exploit différente. Existe-t-il un moyen d'exécuter du code PHP arbitraire avec ce mécanisme (sans utiliser aucune des fonctions ci-dessus)? Ou peut-il seulement être utilisé abusivement pour changer le contenu des variables? Si je manque quelque chose, je veux bien faire les choses.
tylerl
6
Vous pouvez également utiliser des fonctions variables qu'il sera impossible de déterminer sans évaluer le script. Par exemple: $innocentFunc = 'exec'; $innocentFunc('activate skynet');.
erisco
Faites également attention à la réflexion.
erisco
6

Je suppose que vous ne pourrez pas vraiment trouver tous les exploits possibles en analysant vos fichiers source.

  • aussi s'il y a de très bonnes listes fournies ici, vous pouvez manquer une fonction qui peut être exploitée

  • il pourrait toujours y avoir un code diabolique "caché" comme celui-ci

$ myEvilRegex = base64_decode ('Ly4qL2U =');

preg_replace ($ myEvilRegex, $ _POST ['code']);

  • vous pouvez maintenant dire, j'étends simplement mon script pour qu'il corresponde

  • mais vous aurez alors ce "code peut-être maléfique" qui est en plus hors de son contexte

  • donc pour être (pseudo-) sûr, vous devez vraiment écrire du bon code et lire vous-même tout le code existant

Andreas Linden
la source
J'ai vu base64_decode () fréquemment utilisé pour le mal dans les logiciels malveillants basés sur Wordpress. Bon ajout à la liste.
Chris Allen Lane
5

Je sais que cela move_uploaded_filea été mentionné, mais le téléchargement de fichiers en général est très dangereux. La seule présence de $_FILESdevrait susciter quelques inquiétudes.

Il est tout à fait possible d'incorporer du code PHP dans n'importe quel type de fichier. Les images peuvent être particulièrement vulnérables aux commentaires de texte. Le problème est particulièrement gênant si le code accepte l'extension trouvée dans les $_FILESdonnées telles quelles.

Par exemple, un utilisateur peut télécharger un fichier PNG valide avec du code PHP incorporé comme "foo.php". Si le script est particulièrement naïf, il peut en fait copier le fichier sous "/uploads/foo.php". Si le serveur est configuré pour permettre l'exécution de scripts dans les répertoires de téléchargement des utilisateurs (souvent le cas et une terrible erreur), alors vous pouvez instantanément exécuter n'importe quel code PHP arbitraire. (Même si l'image est enregistrée au format .png, il pourrait être possible d'exécuter le code via d'autres failles de sécurité.)

Une liste (non exhaustive) de choses à vérifier lors des téléchargements:

  • Assurez-vous d'analyser le contenu pour vous assurer que le téléchargement est du type qu'il prétend être
  • Enregistrez le fichier avec une extension de fichier connue et sûre qui ne sera jamais exécutée
  • Assurez-vous que PHP (et toute autre exécution de code) est désactivé dans les répertoires de téléchargement des utilisateurs
Matthieu
la source
5

Ajoutons pcntl_signalet pcntl_alarmà la liste.

Avec l'aide de ces fonctions, vous pouvez contourner toute restriction set_time_limit créée dans le php.ini ou dans le script.

Ce script, par exemple, fonctionnera pendant 10 secondes malgré set_time_limit(1);

(Le mérite revient au tweet et à l' essentiel de Sebastian Bergmann :

<?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";
}
édorien
la source
4

Il existe de nombreux exploits PHP qui peuvent être désactivés par les paramètres du fichier PHP.ini. Un exemple évident est register_globals, mais selon les paramètres, il peut également être possible d'inclure ou d'ouvrir des fichiers à partir de machines distantes via HTTP, ce qui peut être exploité si un programme utilise des noms de fichiers variables pour l'une de ses fonctions include () ou de gestion de fichiers.

PHP permet également d'appeler des fonctions variables en ajoutant () à la fin d'un nom de variable - par exemple, $myvariable();il appellera le nom de fonction spécifié par la variable. C'est exploitable; Par exemple, si un attaquant peut obtenir que la variable contienne le mot «eval» et contrôler le paramètre, alors il peut faire tout ce qu'il veut, même si le programme ne contient pas réellement la fonction eval ().

Spudley
la source
4

Ces fonctions peuvent également avoir des effets désagréables.

  • str_repeat()
  • unserialize()
  • register_tick_function()
  • register_shutdown_function()

Les deux premiers peuvent épuiser toute la mémoire disponible et les derniers continuent d'épuiser ...

Alix Axel
la source
2

Il y a eu quelques discussions à ce sujet sur security.stackexchange.com récemment

fonctions pouvant être utilisées pour l'exécution de code arbitraire

Eh bien, cela réduit un peu la portée - mais comme 'print' peut être utilisé pour injecter du javascript (et donc voler des sessions, etc.), c'est toujours quelque peu arbitraire.

ne consiste pas à répertorier les fonctions qui devraient être mises sur liste noire ou autrement interdites. Plutôt, j'aimerais avoir une liste grep-able

C'est une approche sensée.

Envisagez cependant d'écrire votre propre analyseur - très bientôt, vous allez trouver une approche basée sur grep hors de contrôle (awk serait un peu mieux). Très bientôt, vous allez également commencer à souhaiter que vous ayez également mis en place une liste blanche!

En plus des plus évidents, je recommanderais de signaler tout ce qui fait une inclusion avec un argument autre qu'un littéral de chaîne. Faites également attention à __autoload ().

symcbean
la source
2

Je crains que ma réponse soit un peu trop négative, mais ...

À mon humble avis, toutes les fonctions et méthodes peuvent être utilisées à des fins néfastes. Considérez-le comme un effet d'entraînement de la néfaste: une variable est affectée à un utilisateur ou à une entrée distante, la variable est utilisée dans une fonction, la valeur de retour de fonction utilisée dans une propriété de classe, la propriété de classe utilisée dans une fonction de fichier, et ainsi de suite. Rappelez-vous: une adresse IP falsifiée ou une attaque d'homme au milieu peut exploiter l'ensemble de votre site Web.

Votre meilleur pari est de trace du début à la fin tout utilisateur possible ou entrée à distance, en commençant par $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file)( si allow_url_fopen est), toutes les autres fonctions / classes traitant des fichiers distants, etc. Vous construisez un profil programatically stack-trace de chaque valeur fournie par l'utilisateur ou à distance. Cela peut être fait par programme en obtenant toutes les instances répétées de la variable et des fonctions ou méthodes affectées dans lesquelles il est utilisé, puis en compilant récursivement une liste de toutes les occurrences de ces fonctions / méthodes, etc. Examinez-le pour vous assurer qu'il passe d'abord par les fonctions de filtrage et de validation appropriées par rapport à toutes les autres fonctions qu'il touche. Ceci est bien sûr un examen manuel, sinon vous aurez un nombre total decase commutateurs égal au nombre de fonctions et de méthodes en PHP (y compris défini par l'utilisateur).

Alternativement, pour gérer uniquement les entrées utilisateur, ayez une classe de contrôleur statique initialisée au début de tous les scripts qui 1) valide et stocke toutes les valeurs d'entrée fournies par l'utilisateur par rapport à une liste blanche des fins autorisées; 2) efface cette source d'entrée (ie $_SERVER = null). Vous pouvez voir où cela devient un peu naziesque.

bob-the-destroyer
la source
Oui bien sûr, comme avec de nombreux langages de programmation, il n'y a pas de fin de façon de cacher vos mauvaises actions. Cependant, je pense que cela manque l'intention de ce que je demandais. Le scénario ressemble à ceci: vous êtes appelé pour aider après le piratage d'un site Web. Le client paiera un supplément si vous pouvez sécuriser son site Web avant le matin. Le site contient 475 fichiers PHP et les détails médico-légaux utiles ont été détruits - vous avez une énorme botte de foin et une aiguille notoirement petite ... par où commencer? (Mon travail de jour en bref)
tylerl
1

Voici une liste des fonctions que mon fournisseur désactive pour des raisons de sécurité:

  • exec
  • dl
  • show_source
  • apache_note
  • apache_setenv
  • closelog
  • debugger_off
  • debugger_on
  • define_syslog_variables
  • échappehellarg
  • Escapeshellcmd
  • ini_restore
  • openlog
  • passer à travers
  • pclose
  • pcntl_exec
  • popen
  • proc_close
  • proc_get_status
  • proc_nice
  • proc_open
  • proc_terminate
  • shell_exec
  • syslog
  • système
  • url_exec
Vladislav Rastrusny
la source
1

La plupart des attaques dans le code utilisent plusieurs sources d'accès ou plusieurs étapes pour s'exécuter. Je rechercherais non seulement un code, ou une méthode contenant du code malveillant, mais toutes les méthodes, fonctions qui l'exécutent ou l'appellent. La meilleure sécurité comprendrait également l'encodage et la validation des données du formulaire à mesure qu'elles entrent et sortent.

Méfiez-vous également de la définition des variables système, elles peuvent ensuite être appelées à partir de n'importe quelle fonction ou méthode du code.

Cninroh
la source
0

Plusieurs dépassements de tampon ont été découverts à l'aide de fonctions de caractères 4 bits qui interprètent le texte. htmlentities () htmlspecialchars ()

étaient au sommet, une bonne défense consiste à utiliser mb_convert_encoding () pour convertir en codage unique avant l'interprétation.

ehime
la source
0

Vous pouvez trouver une liste constamment mise à jour des récepteurs sensibles (fonctions php exploitables) et de leurs paramètres dans RIPS /config/sinks.php, un analyseur de code source statique pour les vulnérabilités des applications PHP qui détecte également les backdoors PHP.

Reiners
la source
RIPS utilise la liste de cette page.
tour