piratgeAu cours d'une vérification de routine l'équipe de Sucuri a détecté une vulnérabilité critique dans l'extension VirtueMart qui pourrait être utilisée par un utilisateur malveillant afin d'obtenir facilement les privilèges de super-administrateur d'un site web.

En effet avec un accès super-administrateur, l'attaquant pourrait prendre le contrôle total d'un site et de sa base de données. Le bug a été découvert la semaine dernière et a immédiatement été corrigé par l'équipe VirtueMart.

Nous vous conseillons d'installer rapidement la dernière mise à jour disponible sur le site de l'éditeur (dernière version en date au 11/09/2014 : 2.6.10c).

Editeur : Virtuemart

Source : Sucuri.net

Et voilà le résultat : un triste constat sur la communication

12 septembre 2014

Sucuri avait initialement publié les détails techniques sur la vulnérabilité, mais les a enlevés à la demande du VirtueMart, car le problème pourrait également affecter (selon l'éditeur) d'autres extensions. La réaction sur les réseaux sociaux ne s'est pas fait attendre avec une levée de bouclier sur la communication de l'équipe de VirtueMart, ses commentaires et affirmations.

Virtuemart twitter

Brian Teeman (brianteeman) | Twitter - Mozilla Firefox 002

La dernière en date à l'heure où je propose cette mise à jour :

akeeba virtuemart

VirtueMart a publié ce jour : Security release of vm2.6.10 and vm2.9.9 pour s'en expliquer, à savoir si elle va convaincre je pense que oui mais le mal est déjà fait et c'est encore l'image de notre CMS qui va en prendre un coup.

Communiquer en public oui mais pas comme cela !

A propos de l'auteur
Stéphane Bourderiou
Nom: Stéphane BourderiouSite Web: https://www.aide-joomla.fr
Fondateur et rédacteur en chef - Fondateur du site SFK
Webmaster en perpétuelle recherche
Derniers articles de l'auteur

Liste des participants qui ont commenté cet article

  • Je dois avouer que je ne comprends pas la réaction de VM lorsqu'ils visent le code natif de JUser. Je pense très sincèrement qu'ils se plantent complètement.

    J'ai vu le code "défaillant"; celui publié par Sucuri. Que montre ce code ? Que VM édite à l'aveugle le contenu de l'enregistrement de l'utilisateur pour y inscrire des données qui se trouve dans une variable type array du nom de $data. Selon Sucuri, $data correspond à des données provenant de $_POST. Donc, de ce que j'ai vu, si tu envoies un 'group_id'=>'superadmin' dans le $_POST (je simplifie), VM ne contrôlerait pas les champs de $data et hop, mettrait à jour JUser.

    Je suis volontairement évasif car je n'ai pas analysé le code, j'ai lu l'article et j'ai vu la portion de code. De ce que j'ai vu; l'erreur est dans VM qui devrait vérifier que $data ne contient que p.ex. les champs nom, prénom, avatar, et d'autres champs "légitimes". VM devrait interdire de $data des champs comme l'appartenance à un groupe. VM devrait le faire. Un bête contrôle.

    Nul n'est à l'abri d'une erreur de programmation, nous sommes tous faillibles mais affirmer que l'erreur est dans Joomla! est une drôle de défense.

    La fonction bind() est là pour matcher un tableau (la variable $data) avec la structure de la table. Ce n'est pas à bind() d'exclure des champs mais bien au code qui l'appelle ==> VM.

    C'est comme dire que si mon composant com_BadCoded qui est faillible aux injections SQL c'est de la faute à Joomla. Non, c'est à com_BadCoded de faire des user validations.

    Maintenant, une fois encore, mon raisonnement ci-dessus est peut-être erroné; ma déduction est faite au départ du code publié par Sucuri. Et de ce que j'ai, ce n'est pas Joomla! core qui est faillible.

  • Merci Christophe pour ce commentaire technique, tu es bien plus à même que moi pour cette analyse. Pour ma part c'est surtout l'ampleur médiatique qui me derange le plus. Franchement cela aurait du se passer autrement, il y a des situations ou il faut savoir mettre son égo de coté... Franchement dommage pour l'image donnée.

  • Et, sur le plan de la communication, peut-être que cela aurait pû être plus efficace. Les uns profitant du buzz et les autres tentant de réagir, peut-être sous le stress. Je n'ai aucun détail quant à la manière utilisée pour communiquer mais, dans ces cas-là, il faut que la personne qui détecte la faille en parle aux programmeurs afin que ceux-ci puissent mettre à disposition un patch et avertir ses utilisateurs. Peut-être que cela ne s'est pas passé comme cela et que c'était foireux. Dommage pour l'image mais, selon moi, J! n'est pas du tout concerné mais bien les deux intervenants; les développeurs du composant et la société qui a communiqué autour.

  • Pour le buzz on s'en passerait bien car le doute par rapport à Joomla est déjà présent dans la presse spécialsée (un exemple entre-autre).
    Les outils de communication privée existent au sein de la communauté J! et c'est vrai que l'équipe de Virtuemart l'a un peu oublié.
    Quant à Sucuri c'est leur cremerie et on ne peut franchement pas les blamer...Ils ont fait leur boulot comme à l'habitude.

    Dernière édition du commentaire 2014-09-13 23:12:48 par Stéphane Bourderiou
  • Très longue réaction de Radek Suski sur ce bug : http://radeks.coffee/159-the-currently-discovered-bug-in-virtuemart-is

    Il ne dit pas autre chose : c'est un bug VM; pas Joomla!.

    Reste que nul développeur (hormis celui qui hiberne depuis cinquante ans et qui hibernera encore cinquante de plus) n'est à l'abri d'une erreur dans sa programmation. Seule la réaction de type "défensive" et "à fleur de peau" de VM est à pointer du doigt comme étant une très mauvaise réponse. Peut mieux faire...

Ajouter un commentaire