PHPMailer victime d'une faille de sécurité critique, un correctif est disponible

PHPMailer victime d’une faille de sécurité critique, un correctif est disponible

2016 et les failles, une histoire d'amour

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

27/12/2016
14

PHPMailer victime d'une faille de sécurité critique, un correctif est disponible

PHPMailer est victime d'une importante faille de sécurité permettant d'exécuter du code arbitraire à distance. Un correctif est disponible avec la version 5.2.18, mais il faut maintenant attendre qu'il soit déployé par les applications utilisant PHPMailer.

Comme son nom l'indique, PHPMailer est une bibliothèque PHP qui permet d'envoyer des emails et que l'on retrouve dans de nombreuses applications comme WordPress, Drupal, Joomla, etc. Cette solution est donc largement utilisée, ce qui est d'autant plus problématique quand une importante faille de sécurité est découverte. C'est justement ce que vient de trouver Dawid Golunski, sur toutes les versions de PHPMailer inférieures à la 5.2.18 (datée du 24 décembre).

Le hacker à l'origine de la découverte explique que via cette brèche, un pirate pourrait exécuter du code arbitraire à distance sur le serveur qui héberge PHPMailer : « Un attaquant pourrait cibler des composants classiques d'un site web tels que les formulaires de contact ou d'inscription, la réinitialisation d'un mot de passe et d'autres qui envoient des emails à l'aide d'une version vulnérable de la classe PHPMailer ».

Dawid Golunski ajoute qu'il a développé un prototype fonctionnel permettant d'utiliser cette faille. Il ne donne par contre pas plus de détails pour le moment afin de laisser à chacun le temps de se mettre à jour avec la version 5.2.18 (ou 5.2.19 qui ne propose que des changements mineurs) de PHPMailer.

Il faudra également attendre que les applications qui utilisent cette classe se mettent à jour (Joomla, Drupal, WordPress, etc.). Dans tous les cas, le hacker promet que tous les détails d'exploitation de cette faille et une vidéo seront publiés prochainement, sans préciser quand exactement. 

14

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (14)


Le 27/12/2016 à 10h 42

Ok, donc pour faire simple :

“Faites la MAJ, je vous expliquerai plus tard ce que ça implique réellement, et comment l’exploiter.”


fred42 Abonné
Le 27/12/2016 à 10h 56

On peut aussi dire :

“Faites la MAJ et protégez-vous avant que je ne dévoile comment trouer votre site.”


Le 27/12/2016 à 11h 02

En étudiant la class avant et après le patch, ça peut donner une indication sur la faille.


Le 27/12/2016 à 12h 00







boogieplayer a écrit :



En étudiant la class avant et après le patch, ça peut donner une indication sur la faille.





Effectivement, l’intérêt d’un programme OpenSource.



Le commit en question :

https://github.com/PHPMailer/PHPMailer/commit/4835657cd639fbd09afd33307cef164edf…



Le 27/12/2016 à 12h 15







bilbonsacquet a écrit :



Effectivement, l’intérêt d’un programme OpenSource.



Le commit en question :

https://github.com/PHPMailer/PHPMailer/commit/4835657cd639fbd09afd33307cef164edf…





Merci. On voit bien le prob sur le test du sender&nbsp;<img data-src=" />



Jos Abonné
Le 27/12/2016 à 12h 37

Pourtant en lisant un des commentaires un mec dit que le sender a déjà été validé dans la function preSend()

Si c’est le cas, je ne comprends pas ou est le pb…


Le 27/12/2016 à 12h 42

C’est mal, ou pas complètement testé quand c’est vide, à ce que je comprends.


Le 27/12/2016 à 12h 57







Jos a écrit :



Pourtant en lisant un des commentaires un mec dit que le sender a déjà été validé dans la function preSend()



Si c'est le cas, je ne comprends pas ou est le pb...







Vu que la faille est une “inclusion de fichier”, je pense que c’est plutôt l’ajout de cette partie qui est important :



if (!(is\_file($this-&gt;Sendmail) and is\_executable($this-&gt;Sendmail))) {     

throw new phpmailerException($this-&gt;lang('execute') . $this-&gt;Sendmail, self::STOP\_CRITICAL);

}





Et ça : \(params = sprintf('-f%s', escapeshellarg(\)this-&gt;Sender));

&nbsp;&nbsp;

(Edit : l’éditeur html des commentaires est bien pourri sur NXI, il ajoute plein d’espaces bizarroïdes un peu partout <img data-src=" />)



Le 27/12/2016 à 14h 47
Jos Abonné
Le 27/12/2016 à 14h 59

Oui, mais s’il vaut null, il peut pas par conséquent injecter du code dedans <img data-src=" />



&nbsp;@bilbonsacquet je pense pas que ça vienne de la puisque ce paramètre est sous contrôle de l’administrateur


Le 27/12/2016 à 16h 11







RaoulC a écrit :



Un mec fournit ce lien sur le github



&nbsp;https://www.saotn.org/exploit-phps-mail-get-remote-code-execution/





Ce lien pointe sur un news de septembre 2014…

&nbsp;



Jos a écrit :



Oui, mais s’il vaut null, il peut pas par conséquent injecter du code dedans <img data-src=" />



&nbsp;@bilbonsacquet je pense pas que ça vienne de la puisque ce paramètre est sous contrôle de l’administrateur





&nbsp;Oui c’est vrai. Je ne sais pas, j’ai pas le courage de plonger dans le code là tout de suite…&nbsp;<img data-src=" />



Le 28/12/2016 à 08h 00







bilbonsacquet a écrit :



Vu que la faille est une “inclusion de fichier”, je pense que c’est plutôt l’ajout de cette partie qui est important :



if (!(is\_file($this-&gt;Sendmail) and is\_executable($this-&gt;Sendmail))) {     

throw new phpmailerException($this-&gt;lang('execute') . $this-&gt;Sendmail, self::STOP\_CRITICAL);

}





Et ça : \(params = sprintf('-f%s', escapeshellarg(\)this-&gt;Sender));

&nbsp;&nbsp;

(Edit : l’éditeur html des commentaires est bien pourri sur NXI, il ajoute plein d’espaces bizarroïdes un peu partout <img data-src=" />)







Oui c’est bien ça le problème, l’injection shell par les paramètres pour sendmail



Le 28/12/2016 à 21h 16

Pour ceux qui n’ont pas suivi, il y a eu des nouvelles mises à jour, car le patch n’était pas suffisant ! Tous les sites ne sont pas concernés en fonction de la mise en application de phpMailer, mais bon, vaut mieux prévenir que guérir !








jackjack2 a écrit :



Oui c’est bien ça le problème, l’injection shell par les paramètres pour sendmail





De fait il me semble en effet que si l’adresse de l’expéditeur est du genre “[email protected] & rm -r *” (ou … & format c: hein…) ça peut faire du dégât… d’où un EscapeShellArg qui devrait aurait dû détecter la chose.