Jusqu’à quel point les communautés en charge des projets open source sont réactives face à la publication des rapports de vulnérabilité ?
Un chercheur indépendant nommé Brandon Perry a réalisé un audit de sécurité pour sept logiciels open source populaires à savoir Moodle, vTiger CRM, Zabbix, ISPConfig, OpenMediaVault, NAS4Free et Openbravo ERP, tous domiciliés sur sourceforge.
Rapidement, Brandon a pu venir à bout des logiciels. Il a ainsi découvert des failles de sécurité pour toutes ces applications, et développé des modules Metasploit pour les exploiter.
Par la suite, les différentes communautés open source responsables des projets ont été alertées. Comme on s’y attendait, leurs réactions ont été promptes.
Les communautés des projets Zabbix, OpenMediaVault, et Moodle ont fait part de leurs intentions de ne créer en aucun moment de patchs pour les vulnérabilités qui leur ont été soumises.
Par contre, les équipes de vTiger CRM, Openbravo ERP et ISPConfig ont publié des correctifs de sécurité.
L’équipe de NAS4Free quant à elle, s’est tenue de toutes formes de commentaires. En effet, elle n’a pas annoncé ses intentions de publier quoi que ce soit.
Cela peut paraître déroutant que des communautés de projets open source ne produisent pas des correctifs pour des vulnérabilités qui leur ont été explicitement adressées. En effet, les vulnérabilités reportées ont toutes besoin que le hacker soit correctement authentifié avec la combinaison nom d’utilisateur et mot de passe, avant de faire quoi que ce soit.
De plus, les communautés réfractaires à la publication de correctifs ont avancé l’argument qu’en fait, il ne s’agissait pas d’une vulnérabilité, mais d’une condition normale de fonctionnement de l’application.
Par ailleurs, le chercheur de Metasploit déplore le fait que les responsables de ces projets open source ne respectent pas scrupuleusement la RFPolicy disponible depuis quelque temps déjà et mise en pratique par les organismes comme Microsoft ou encore Apache.
Ladite politique décrit précisément les relations que le chercheur en sécurité qui a découvert la faille et les responsables de la maintenance du logiciel concerné doivent entretenir avant la publication officielle de la vulnérabilité. En effet, la RFPolicy stipule que le chercheur contacte les mainteneurs du logiciel pour leur faire part de la vulnérabilité découverte, et ceux-ci sont tenus d'apporter les correctifs nécessaires avant que la faille ne soit rendue publique.
Or, pour certains des logiciels testés, les mainteneurs ont soumis la vulnérabilité à un "Bug Tracker List" où l'échange de message se faisait en texte clair.
Pour terminer, Tod Beardsley de Rapid7 donne huit bonnes pratiques pour améliorer le processus de suivies des vulnérabilités logicielles depuis leur découverte jusqu'à leur publication. C'est ainsi qu'il recommande entre autres, d'utiliser un bon format pour l'adresse mail à laquelle les chercheurs devront envoyer les découvertes de failles logicielles, d'utiliser PGP (Pretty Good Privacy) pour chiffrer les communications, ou encore aux mainteneurs logiciels d'accusé réception d'un mail en relation avec la découverte d'une vulnérabilité qui leur a été adressée par un chercheur.
Source: Blog Rapid7
Et vous ?
Quelle est votre opinion ?
Les responsables des projets Zabbix, OpenMediaVault, et Moodle ont-ils raison de ne pas publier de correctifs ?
Un chercheur remet en question la gestion des failles de sécurité des projets open source
Et propose quelques bonnes pratiques
Un chercheur remet en question la gestion des failles de sécurité des projets open source
Et propose quelques bonnes pratiques
Le , par Cedric Chevalier
Une erreur dans cette actualité ? Signalez-nous-la !