Est-il possible de trouver un débordement de tampon dans WordPress?
J'ai eu une conversation intéressante avec un pentester qui m'a dit qu'il avait trouvé un débordement de tampon dans Wordpress. La personne en question était vraiment convaincue que c'était vrai. Le client est un peu sceptique quant aux compétences techniques de la firme de pentesting et m'a demandé mon avis.
Donc, la question que j'ai est la suivante: quelqu'un a-t-il déjà entendu dire que quelqu'un avait trouvé un débordement de tampon dans WordPress en faisant simplement une demande GET à un PHP?
Mon avis: Si c'était vrai, il aurait trouvé un débordement de tampon dans l'interpréteur PHP, et ce serait énorme. Donc je ne pense pas que ce soit vrai.
EDIT: Le BOF était à deux endroits:
Dans une fonction php construite par le client avec la même charge utile qu'une vulnérabilité XSS (donc quelque chose comme 123 "> alert (0);
Dans le jeton wp_session avec juste un tas de A (~ 60)
Tout a été fait en externe sans accès au serveur dans un pentest rapide de routine d'environ 10 sites Web différents ...
Je mettrai à jour après avoir fait une revue de code réelle sur les parties qui devraient être vulnérables
EDIT: J'ai donc fait la révision du code et c'était en effet une histoire BS. Non seulement les BOF n'existaient pas du tout, mais il a en fait déclaré avoir trouvé un SQLi dans une partie du code qui ne faisait absolument rien avec une base de données.
Mais au moins la discussion dans les commentaires était très perspicace sur les possibilités de BOF de ce type de plates-formes standard et de CMS, j'ai donc beaucoup appris! Merci!
Comme PHP fait la gestion de la mémoire et beaucoup de choses en soi, trouver un débordement de tampon spécifiquement dans WordPress n'a pas vraiment de sens pour moi.
Avant de discréditer ce testeur de pénétration, je lui demanderais la documentation de la conclusion en question. Comme il/elle travaille pour ledit client (ça sonne, corrigez-moi si je me trompe), c'est son travail pour signaler un tel problème au client, y compris une documentation d'au moins un moyen de retrouver/reproduire le problème.
Je suis très sceptique, comme vous le dites, qu'il/elle n'a eu accès au service web que de l'extérieur. La vérification d'un problème de bas niveau comme un débordement de tampon (qui est même bien au-delà du service Web ou wordpress en général) est presque impossible de l'extérieur.
En exécuter un est délicat, même si vous avez accès au code source, ce qui ne semble pas être le cas (en supposant qu'il ne s'agit pas d'un test de boîte blanche).
P.S .: Si vous obtenez une réponse du client/pentester, j'aimerais l'entendre. Vous m'avez rendu assez curieux pour une raison quelconque ...
Il se peut qu'il ait trouvé un débordement de tampon dans PHP ou glibc qui peut être exploité via Wordpress. Par exemple, il y a 3 ans, il y avait un trou dans gethostbyname () qui pourrait être exploité via Wordpress. Cela s'appelle la vulnérabilité GHOST.
Si vous avez un très ancien système d'exploitation sans mises à jour ainsi qu'un très ancien Wordpress cela pourrait être vrai.
Comme GxTruth l'a mentionné , PHP fait la gestion de la mémoire. Cela signifie que tout ce qui fonctionne sur php est fondamentalement aussi sécurisé contre les dépassements de tampon que le php (sauf si vous faites quelque chose de vraiment fou) ).
Mais php n'est pas à 100% à l'abri des débordements de tampon: https://stackoverflow.com/questions/11817576/is-php-buffer-overflow-possible
Si ce pentester a effectivement trouvé un débordement de tampon, il devrait pouvoir vous dire exactement comment le reproduire. À ce stade, vous devriez pouvoir retracer cela dans le code. Cela peut être dû à une version précédemment corrigée de WP/PHP. Assurez-vous toujours que vous êtes à jour sur les derniers correctifs de l'ensemble de votre pile technologique.
S'il s'avère qu'il s'agit d'un bogue dans les versions les plus récentes, collectez les informations pertinentes et déposez les rapports de bogue appropriés. Vous pouvez informer les personnes qui développent php ici: http://bugs.php.net/ . Assurez-vous de marquer votre bogue comme lié à security. Il serait également pertinent de lire ceci en premier: https://wiki.php.net/security . Signalez également cela à WordPress ou à tout développeur de plugins/thèmes tiers concernés afin qu'ils puissent prendre des mesures pour atténuer le problème pendant que PHP lui-même est patché.
Et si c'est un problème, aussi curieux que nous puissions être d'entendre ce que c'est, ne pas faire rapport publiquement à ce sujet jusqu'à ce que les responsables du code affecté avoir une chance de le réparer car cela affectera de nombreux sites sur le Web et pas seulement le vôtre.
C'est probablement l'un de ces quatre:
- Il peut ne pas connaître le nom correct et appeler quelque chose comme hashdos un "buffer overflow" car il remplit le tableau à un point tel qu'il ne répond plus ou se bloque.
- Il a peut-être trouvé un débordement de tampon dans PHP et, pour les profanes, l'appeler "dans Wordpress" parce que les gens ne savent peut-être pas qu'ils exécutent PHP sous le capot) et je ne le connais que sous Wordpress.
- Il a peut-être trouvé un débordement de tampon pour PHP pour être exploitable via Wordpress.
- Il n'a peut-être aucune idée de ce dont il parle.
Je dirais que ce dernier est de loin le plus probable.
Il est possible qu'il ait trouvé un débordement de tampon dans le serveur Web (par exemple Apache HTTPD) lui-même, au lieu de php ou de votre application. Par exemple, https://www.cvedetails.com/cve/CVE-1999-0071/ "Débordement de la mémoire tampon des cookies Apache httpd pour les versions 1.1.1 et antérieures.", Ce CVE bloque l'enfant Apache par exemple au cas où le serveur utilise mod_cookie pour modifier un cookie dans la réponse HTTP. Si je me souviens bien, si l'attaquant mettait une longue chaîne dans la valeur de cookie appropriée, cela provoquait le crash.