Discussion :

[Cedric Chevalier]

Un chercheur remet en question la gestion des failles de sécurité des projets open source
et propose quelques bonnes pratiques


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 ?

[Mishulyna]

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.


Et vous ?

Quelle est votre opinion ?

"It's not a bug, it's a feature!"

[Traroth2]

Il a choisi des projets pas très connus (je ne connaissais que Zabbix, personnellement), et il en tire des conclusions pour toute la communauté open-source. Ça parait plutôt spécieux.

Ensuite et surtout, il serait effectivement intéressant de savoir quels sont les fameuses vulnérabilités en question, et ce que font les "exploits" il affirme avoir été en mesure d'écrire. Si les personnes qui maintiennent ces projets affirment qu'il ne s'agit pas de vulnérabilité alors que lui dit l'inverse, lui donner raison sans plus d'explication ne me parait pas très sérieux.

[6-MarViN]

Il a choisi des projets pas très connus (je ne connaissais que Zabbix), et il en tire des conclusions pour toutes la communauté open-source. Ca parait plutôt spécieux.

Ensuite et surtout, il serait effectivement intéressant de savoir quels sont les fameuses vulnérabilités en question, et ce que font les "exploits" il affirme avoir été en mesure d'écrire. Si les personnes qui maintiennent ces projets affirment qu'il ne s'agit pas de vulnérabilité alors que lui dit l'inverse, lui donner raison sans plus d'explication ne me parait pas très sérieux.

Moodle est quand meme relativement connu.

Ensuite pour ce qui est de Zabbix, le tableau affiche que la faille est que l'on peut executer une commande sur un OS apres authentification. Or Zabbix etant un outil de monitoring permettant d'executer des commande distantes pour resoudre des probleme (par example redemarrer un serveur Apache qui tombe), il est normal que cela soit possible. La vrai faille serait de pouvoir faire ca AVANT l'authentification.

[Traroth2]

Moodle est quand meme relativement connu.

Ensuite pour ce qui est de Zabbix, le tableau affiche que la faille est que l'on peut executer une commande sur un OS apres authentification. Or Zabbix etant un outil de monitoring permettant d'executer des commande distantes pour resoudre des probleme (par example redemarrer un serveur Apache qui tombe), il est normal que cela soit possible. La vrai faille serait de pouvoir faire ca AVANT l'authentification.

Ah oui, j'avais zappé cette colonne. En fait, toutes les "vulnérabilités" sont post-authentification. C'est donc une notion de la vulnérabilité qui est quand même assez... particulière.

[fredoche]

Ah oui, j'avais zappé cette colonne. En fait, toutes les "vulnérabilités" sont post-authentification. C'est donc une notion de la vulnérabilité qui est quand même assez... particulière.

pas du tout

c'est plutôt penser que n'importe quel utilisateur loggué est digne de confiance qui est une notion assez particulière

La sécurité ce n'est pas juste authentifier un utilisateur, c'est aussi gérer ses privilèges, l'autorité dont il dispose au sein de l'application.

J'ai regardé au moins pour Moodle le mécanisme qui est bien un XSS, cela permet de modifier les privilèges tout en usurpant une identité.

Quand dans une appli tu gères différents rôles, c'est gênant tout de même.

Si une fois loggué sur mon compte en banque, j'accède à celui de l'ensemble des clients de la banque, ça va être "la fête du slip "

[tontonnux]

Moi, j'ai trouvé une grosse faille de sécurité dans phpMyadmin.
En effet, une fois qu'on est identifié avec un compte qui dispose de suffisamment de droits, on peut faire un DROP DATABASE (wé, carrément !).



<<<<<*

*already out...

[Traroth2]

Moi, j'ai trouvé une grosse faille de sécurité dans phpMyadmin.
En effet, une fois qu'on est identifié avec un compte qui dispose de suffisamment de droits, on peut faire un DROP DATABASE (wé, carrément !).



<<<<<*

*already out...

Pas besoin de sortir. C'est de cet ordre, les "vulnérabilités" que cet "expert" a trouvé. J'imagine bien la gueule des "exploits", là...

[imikado]

La gestion est a peu près la même que pour le propriétaire: on averti l'editeur/responsable du projet et il prend ou non du temps pour corriger le produit.

La seul différence avec un projet opensource, c'est qu'au pire, si le responsable ne veut vraiment pas corriger des failles sur son projet, il verra rapidement naitre un fork les corrigeant

[Squisqui]

si le responsable ne veut vraiment pas corriger des failles sur son projet, il verra rapidement naitre un fork les corrigeant

Avant de forker, il est sans doute moins pénible de réussir à fournir un patch (qui, en cas de non intégration servira au fork).

[TotemRajal]

Quelle est votre opinion ?

Résumer l'Open Source a 7 logiciels je trouve cela peu crédible. L'étude serais en effet intéressante sur un plus grand nombre. Pour le moment c'est une étude a l'emporte pièce.

Les responsables des projets Zabbix, OpenMediaVault, et Moodle ont-ils raison de ne pas publier de correctifs ?

Pour ma part non. C'est bien pour cela que je ne les utilise pas !
Maintenant un petit rappel :
Adhérer à la communauté OpenSource ce n'est pas seulement utiliser mais c'est aussi reporter et si on a les compétences ou que le correctif a été trouvé c'est de faire partager/publier ce correctif à tous et surtout aux développeur qui ont si gentiment fournit le logiciel gratuitement avec leur code et tout et tout.....