Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    juin 2016
    Messages
    920
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 920
    Points : 25 538
    Points
    25 538
    Par défaut Un bogue d'exécution de code à distance a été découvert dans PHP 7
    Un bogue d'exécution de code à distance a été découvert dans PHP 7
    et permet même aux attaquants non techniques de prendre le contrôle des serveurs à distance

    Il a été récemment découvert dans PHP 7, la dernière version du langage, une faille de sécurité dangereuse et facile à exploiter, car elle permettrait même aux attaquants non techniques de prendre le contrôle des serveurs à distance. La vulnérabilité, qui a été corrigée la semaine dernière, est une exécution de code à distance (RCE) en PHP 7 permettant d’attaquer un serveur Web vulnérable en envoyant des requêtes spécialement conçues et en ajoutant "?a=" dans l'URL. Seuls les serveurs Nginx couplés à l’extension PHP-FPM sont vulnérables.

    Dans le registre des bogues de PHP, cette faille est désignée par CVE-2019-11043 et permet aux attaquants d'exécuter des commandes sur les serveurs simplement en accédant à une URL spécialement conçue. Le code d'exploitation de preuve de concept (PoC) public a été publié sur GitHub dans la semaine passée. Le hacker teste d’abord le serveur cible et s’il reçoit une réponse favorable, il peut maintenant lancer son attaque.

    La vulnérabilité a été découverte par Andrew Danau, chercheur en sécurité chez Wallarm, une société de cybersécurité sise à San Francisco. Il est tombé sur un comportement inhabituel d'un script PHP lors de la résolution d'une tâche du FCT. Quand Danau a envoyé les octets %0a (newline) dans l'URL, la réponse du serveur était particulière. Il renvoie plus de données qu'il ne devrait y en avoir. De plus, Wallarm a précisé que la quantité de données supplémentaires renvoyées était liée au nombre d'octets après %0a à l'intérieur de l'URL.

    Nom : phpwallpv2-570x350.png
Affichages : 47845
Taille : 61,6 Ko

    « Le plus souvent, ce genre de réaction est lié aux attaques de corruption de la mémoire et nous nous attendions à ce qu'il y ait une attaque contre le type de divulgation de l'information. La divulgation d'informations est déjà assez mauvaise, car elle peut entraîner des fuites de données sensibles ou financières. Pire encore, de temps en temps, bien que très rarement, un tel comportement puisse indiquer une vulnérabilité d'exécution du code à distance », a décrit Wallarm dans un billet de blogue qui explique comment résoudre le problème.

    Le script PoC inclus dans le référentiel GitHub peut interroger un serveur Web cible pour vérifier s'il est vulnérable ou non en envoyant des requêtes spécialement conçues. Une fois qu'une cible vulnérable a été identifiée, les attaquants peuvent envoyer des requêtes spécialement conçues en ajoutant « ?a= » dans l'URL à un serveur Web vulnérable. Dans certaines configurations Nginx + PHP-FPM, le bogue peut être déclenché de l'extérieur. Cela signifie qu'un utilisateur Web peut obtenir l'exécution de code si vous avez une configuration vulnérable.

    Autrement dit, seuls les serveurs Nginx avec l’extension PHP-FPM sont vulnérables à cette faille. L’exploit ne fonctionne que sous la version 7 de PHP. En effet, le bogue est lié à un débordement de tampon (buffer underflow) dans PHP-FPM. Le buffer underflow en PHP-FPM est aussi présent dans PHP 5, mais l'attaquant peut exploiter une optimisation utilisée pour stocker les variables FastCGI, _fcgi_data_seg. Cette optimisation n'est présente que dans PHP 7.

    Ainsi, cette faille n'existe que sur PHP 7. Néanmoins, il peut y avoir une autre technique d'exploitation qui fonctionne pour PHP 5. Pour l’heure, chaque administrateur se doit donc de mettre à jour PHP 7 pour éviter d’être la cible d’une attaque vers les versions les plus récentes, 7.3.11 et 7.2.24, publiées le même jour et incluant les correctifs pour CVE-2019-11043. Mais, il y a aussi des propriétaires de sites Web qui ne peuvent pas mettre à jour PHP ou qui ne peuvent pas passer de PHP-FPM à un autre processeur CGI en raison de contraintes techniques.

    Si c’est le cas, le billet de Wallarm montre comment les webmasters peuvent utiliser l'utilitaire de pare-feu standard « mod_security » pour bloquer les octets %0a (newline) dans les URL des sites, et empêcher toute attaque entrante. Une règle « mod_security » pourrait ressembler à ceci : « SecRule REQUEST_URI “@rx %0(a|d)” “id:1,phase:1,t:lowercase,deny” ». Cependant, si vous avez une application de par-feu hérité et appliquez cette règle, le niveau de faux positifs sera élevé. Cela est assez commun pour les par-feux de première génération basés sur une expression RegEx.

    D’après Wallarm, sans correction, ce problème peut devenir un point d'entrée dangereux dans vos applications Web, dont la plupart s'exécutent sur une infrastructure PHP. En raison de la disponibilité du code public PoC et de la simplicité d'exploitation de ce bogue, il est conseillé aux propriétaires de sites Web de vérifier les paramètres du serveur et de mettre à jour PHP dès que possible s'ils utilisent la configuration vulnérable.

    Sources : PHP, Wallarm, PoC (GitHub)

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi

    Quel langage de programmation comporte le plus de vulnérabilités en matière de sécurité ? Une étude de WhiteSource

    Une vulnérabilité inhérente à PHP met à risque des millions de sites web WordPress et l'équipe du CMS ne l'a toujours pas corrigée depuis 2017

    Une vulnérabilité 0-day dans un plugin jQuery permettrait de télécharger et d'exécuter du code malveillant sur des serveurs PHP, et ce depuis 2010
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre à l'essai Avatar de Jonathan muswil
    Homme Profil pro
    informatitien
    Inscrit en
    juillet 2018
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 22
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : informatitien

    Informations forums :
    Inscription : juillet 2018
    Messages : 19
    Points : 11
    Points
    11
    Par défaut
    On dirait le developper de php doivent mettre a jour leur platforme pour corriger sa je pense sinon pour eux ce oufff danger ???

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    mars 2011
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2011
    Messages : 35
    Points : 82
    Points
    82
    Par défaut
    Citation Envoyé par Jonathan muswil Voir le message
    On dirait le developper de php doivent mettre a jour leur platforme pour corriger sa je pense sinon pour eux ce oufff danger ???
    Je n'ai pas compris.

  4. #4
    Membre émérite
    Homme Profil pro
    Responsable informatique, développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    601
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Responsable informatique, développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 601
    Points : 2 790
    Points
    2 790
    Par défaut
    Citation Envoyé par smobydick Voir le message
    Je n'ai pas compris.
    Il y avait peu être rien à comprendre...

  5. #5
    Membre averti
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 117
    Points : 340
    Points
    340
    Par défaut
    @Jonathan muswil, Quoi ?
    @smobydick & @sergio_is_back,

    Qu'en pensez-vous ?
    Laisser un environnement d’exécution complet côté serveur de prod me parait être de moins en moins une bonne idée .
    Mais bon, c'est un peut une obligation au vue des contraintes de temps imposées par les clients .
    Donc c'est aussi leurs fautes quelque part .

  6. #6
    Membre actif
    Homme Profil pro
    PDG
    Inscrit en
    septembre 2005
    Messages
    101
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : PDG
    Secteur : Arts - Culture

    Informations forums :
    Inscription : septembre 2005
    Messages : 101
    Points : 204
    Points
    204
    Par défaut
    D'après ce que je comprends, le problème vient plutôt de la configuration de nginx. La preuve en est que ça n'arrive pas avec Apache et qu'il suffit de modifier la configuration de nginx pour que ce soit corrigé.
    Passer à PHP un string qui comporte un retour à la ligne n'a rien d'exceptionnel, par contre, passer une URI qui en comporte l'est (sauf dans le cas d'un GET particulier...).

  7. #7
    Membre averti
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 117
    Points : 340
    Points
    340
    Par défaut
    Citation Envoyé par dasdeb Voir le message
    D'après ce que je comprends, le problème vient plutôt de la configuration de nginx.
    La preuve en est que ça n'arrive pas avec Apache et qu'il suffit de modifier la configuration de nginx pour que ce soit corrigé.
    Passer à PHP un string qui comporte un retour à la ligne n'a rien d'exceptionnel, par contre, passer une URI qui en comporte l'est (sauf dans le cas d'un GET particulier...).
    Oula, c'est un beau sophisme ça.
    Le problème ne vient pas de NGINX pour autant, mais du couple NGINX/PHP-FPM (d'après l'article), c'est donc normale qu'il n’apparaisse pas avec Apache, mais ça n'en fait pas pour autant un problème de NGINX.

    D’ailleurs en consultant le CVE-2019-11043 Detail
    In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers into the space reserved for FCGI protocol data, thus opening the possibility of remote code execution.
    On comprend que le problème viendrait en réalité du module PHP-FPM et donc qu'il pourrait aussi bien toucher Apache, qu'NGINX (qui n'est même pas évoqué dans la description de cette CVE) ou qu'un autre serveur l'utilisant.

Discussions similaires

  1. [Drupal] Des millions de sites Web menacés par un bogue d'exécution de code extrêmement critique dans Drupal
    Par Stéphane le calme dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 5
    Dernier message: 04/03/2019, 16h01
  2. Réponses: 0
    Dernier message: 17/12/2018, 22h44
  3. Réponses: 0
    Dernier message: 14/05/2018, 21h01
  4. Réponses: 0
    Dernier message: 05/06/2015, 07h37
  5. Exécuter le code VBA d'un module dans un sous formulaire
    Par keketteboy dans le forum VBA Access
    Réponses: 2
    Dernier message: 04/06/2008, 12h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo