Connexion
Abonnez-vous

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

2016 et les failles, une histoire d'amour

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

Le 27 décembre 2016 à 07h39

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. 

Commentaires (14)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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 !

votre avatar







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.


votre avatar

Ok, donc pour faire simple :

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

votre avatar

On peut aussi dire :

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

votre avatar

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

votre avatar







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 :

github.com GitHub


votre avatar







bilbonsacquet a écrit :



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



Le commit en question :

github.com GitHub





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


votre avatar

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…

votre avatar

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

votre avatar







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=" />)


votre avatar
votre avatar

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

votre avatar







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=" />


votre avatar







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


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

Fermer