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.

[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...

[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

[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à...

[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 "

[Traroth2]

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 "

Ca dépend fortement du type d'application, ce que tu dis. Toutes les applications ne gèrent pas de notion de rôle, justement. Pour Zabbix, par exemple, ces affirmations me paraissent carrément fantaisistes. Et là, ça entame quand même méchamment sa crédibilité. Déjà qu'il a quand sélectionné des projets pas franchement parmi les plus importants de la planète, ce qui me parait quand même une coïncidence un peu bizarre, on peut commencer à se poser des questions sur sa bonne foi.

Bon, je vais me fendre de lire en détail, mais comme dit, à partir du moment où le type raconte du bullshit sur un des sujets, quelle crédibilité accorder au reste de ces propos ?

-Moodle, effectivement, la faille est sérieuse. Moodle est une plateforme de e-learning, et un "étudiant" (utilisateur sans privilèges) peut accéder au statut admin. Je dois reconnaitre que j'avais déjà entendu parler de cette application, à la réflexion.
-vTiger (il n'explique même pas ce que c'est. Pas évident pour replacer le comportement problématique dans le contexte général du fonctionnement de l'application). Déjà, il faut avoir les droits admin pour utiliser l'exploit, qui permet d'uploader des scripts php avec l'extension "php3". Le bug a là été corrigé par l'équipe.
-Zabbix, qui est une application de monitoring système. La "faille", c'est qu'un administrateur peut exécuter une commande shell à distance, y compris sur localhost. Vus les cas d'usage de Zabbix, on a du mal à voir l'aspect problématique. Au mieux, il coupe les cheveux en quatre, si on veut être indulgent.
-Openbravo ERP a corrigé la faille, qui permettait à un utilisateur authentifié de downloader des fichiers situés sur le serveur
-ISPConfig a aussi été corrigé. La faille permettait à un administrateur d'uploader un script PHP sur le serveur et de le faire exécuter...
-OpenMediaVault est une variante de Debian Linux, apparemment. Il est possible de créer un cron qui exécute un script, même en root. J'aurais tendance à dire qu'en root, il doit même être possible de faire un rm -rf /*, mais j'ai du mal à y voir quelque chose d'anormal.
-NAS4Free est une variante de système BSD. Il est donc possible entre autre d'exécuter un script PHP. Là aussi, je pense qu'on peut faire bien pire, mais je ne vois toujours pas où est le problème.

Franchement, le cas de Moodle me semble le seul réellement problématique. Le reste est vraiment tiré par les cheveux coupés en quatre.

[Traroth2]

J'ajouterais que, pour Moodle, j'aimerais bien connaitre le numéro d'incident, parce que je n'ai pas trouvé sur le JIRA...

https://tracker.moodle.org/secure/Dashboard.jspa

C'est dommage, les commentaires de l'équipe de Moddle m'auraient intéressés.

[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).

[Traroth2]

Les choses sont finalement très différentes. En cherchant dans le JIRA de Moodle l'intitulé utilisé sur le blog de notre "expert", c'est à dire "Authenticated Remote Command Execution", j'ai trouvé uniquement l'incident suivant :

https://tracker.moodle.org/browse/MDL-17207

Plusieurs remarques :

-Le bug n'a pas du tout été trouvé par le type en question
-C'est un bug spécifique à la version 1.9 à 1.9.3, qui n'existait pas dans les versions 1.8 et précédentes
-Le bug a bel et bien été corrigé dans la version 1.9.4 !
-Ca date quand même de fin 2008

Je ne sais pas si c'est le bon incident, mais si oui, il ne reste pas grand chose de cette "étude". Et si non, encore une fois, j'aimerais bien avoir le numéro d'incident...

Edit : Non, ce n'est probablement pas cet incident, d'après la description. Mais c'est le seul qui mentionne "Authenticated Remote Command Execution" dans le JIRA de Moodle...

[fredoche]

Ca dépend fortement du type d'application, ce que tu dis. Toutes les applications ne gèrent pas de notion de rôle, justement. Pour Zabbix, par exemple, ces affirmations me paraissent carrément fantaisistes. Et là, ça entame quand même méchamment sa crédibilité. Déjà qu'il a quand sélectionné des projets pas franchement parmi les plus importants de la planète, ce qui me parait quand même une coïncidence un peu bizarre, on peut commencer à se poser des questions sur sa bonne foi.

Bon, je vais me fendre de lire en détail, mais comme dit, à partir du moment où le type raconte du bullshit sur un des sujets, quelle crédibilité accorder au reste de ces propos ?

-Moodle, effectivement, la faille est sérieuse. Moodle est une plateforme de e-learning, et un "étudiant" (utilisateur sans privilèges) peut accéder au statut admin. Je dois reconnaitre que j'avais déjà entendu parler de cette application, à la réflexion.
-vTiger (il n'explique même pas ce que c'est. Pas évident pour replacer le comportement problématique dans le contexte général du fonctionnement de l'application). Déjà, il faut avoir les droits admin pour utiliser l'exploit, qui permet d'uploader des scripts php avec l'extension "php3". Le bug a là été corrigé par l'équipe.
-Zabbix, qui est une application de monitoring système. La "faille", c'est qu'un administrateur peut exécuter une commande shell à distance, y compris sur localhost. Vus les cas d'usage de Zabbix, on a du mal à voir l'aspect problématique. Au mieux, il coupe les cheveux en quatre, si on veut être indulgent.
-Openbravo ERP a corrigé la faille, qui permettait à un utilisateur authentifié de downloader des fichiers situés sur le serveur
-ISPConfig a aussi été corrigé. La faille permettait à un administrateur d'uploader un script PHP sur le serveur et de le faire exécuter...
-OpenMediaVault est une variante de Debian Linux, apparemment. Il est possible de créer un cron qui exécute un script, même en root. J'aurais tendance à dire qu'en root, il doit même être possible de faire un rm -rf /*, mais j'ai du mal à y voir quelque chose d'anormal.
-NAS4Free est une variante de système BSD. Il est donc possible entre autre d'exécuter un script PHP. Là aussi, je pense qu'on peut faire bien pire, mais je ne vois toujours pas où est le problème.

Franchement, le cas de Moodle me semble le seul réellement problématique. Le reste est vraiment tiré par les cheveux coupés en quatre.

tu as regardé ce post ?
https://community.rapid7.com/communi...cks-and-treats

vtiger c'est un outil de CRM : Customer Relationship Management c'est assez vaste comme domaine d'application. Je ne connais pas le produit.

perso je gère et dev une appli avec des roles, des droits, c'est une appli dite SaaS.

Il est clair que sur cette application ceux qui ont des droits d'administrateurs ne sont aps ceux qui ont des droits d'admin sur le reste de la mahcine, à savoir OS, file system et SQL.

Il faut bien distinguer ces rôles, moi je comprends ce qui se dit ici. Et pour moi, ce n'est aps du bullshit, c'est une info intéressante.
Si par le biais de mon appli, l'utilisateur même admin acquiert des droits qu'il n'est pas censé posséder, notamment aux couches inférieures cela peut être problématique.

Tout cela me semble être des fondements notamment de ssytèmes comme les sytèmes UNIX/LINUX, qui sont batis sur le principe du POLA :

In information security, computer science, and other fields, the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user or a program depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose

extrait de http://en.wikipedia.org/wiki/Princip...east_authority

Regarde au bas de la page qui détaille les failles. L'auteur précise bien que ce sont des expositions, pas des vulnérabilités.

Pense au Saas ou même à la logique de base selon laquelle toi pro informaticien tu mets en place une solution pour un client dont tu fais la TMA mais dont tu ne fais pas l'usage. ce risque est à envisager.

je vais chercher ma fille à l'école, désolé de ne pouvoir plus développer

[imikado]

@Squisqui bien sur le mieux est qu'il corrige ou accepte le patch, le parlait du cas où il ne voulait pas corriger

[Traroth2]

@fredoche :

"tu as regardé ce post ?" : Oui, j'ai mis le lien dans un de mes (trop ?) nombreux posts...

Pour le reste, je pense que les explications de l'article sont trop vagues pour permettre de déterminer le niveau de sévérité des problèmes en question. A part Moodle, mais là, je ne vois pas de trace du "won't fix" dont il parle sur le bugtracking du projet.

"L'auteur précise bien que ce sont des expositions, pas des vulnérabilités" : Oui, j'ai bien vu ça. Mais le titre, lui, parle bien de vulnérabilités, et là, on repose sur le problème de l'honnêteté de cette étude.

[fredoche]

Relis chacune des descriptions, mets toi dans cette situation où tu mets à disposition ces applications pour des clients, sans jouer le rôle d'admin de l'application, mais simplement des systèmes sous-jacents : OS, BDD, FS et accès réseaux.
Si tu distingues ces deux admin, tu ne voudras pas que l'admin de l'appli puisse bénéficier de tes privilèges sur le reste de la machine

La démarche que le mec a entreprise pour trouver ces failles est ouverte à tous puisque les sources sont ouverts. Il ne met pas en évidence des failles qui compromettent directement les applications, mais des failles potentielles qui permettent la compromission des systèmes sous-jacents par le biais de l'application qui est hostée.
A partir du sous-jacent, tu pourras casser l'appli elle-même ensuite, question de privilège.

Mais pas forcément, cela peut juste un point d'entrée sur ton réseau, pour accéder d'autres machines, ou que sais-je.
De plus la discrétion est de mise.

Considère que l'admin de l'application et l'admin des systèmes sous-jacents sont 2 personnes différentes avec des intérêts différents, imagine des machines d'hébergement mutualisés (possible pour toutes ces applis, et surtout ISPconfig), et là tu comprends que ces risques existent bien, que ce n'est pas du bullshit.

Rapid7 vend des applis d'audit de sécurité, ils prêchent pour leur paroisse, c'est sur... mais quand même.
Tu peux aussi comprendre qu'une appli qui permet d'obtenir des privilèges autres que ceux qui servent à l'appli, comme par exemple d'implanter un PHP discret et exécutable, avec le niveau de privilège qui est celui de l'application exploitée, c'est effectivement un problème qui peut se révéler critique.

Avec php qui est ultra riche en fonctionnalités, tu peux en faire des choses

Dans ces exemples, on casse le POLA, le principe du moindre privilège, ce sont de réelles portes.

Je pense que vous réagissez de manière trop épidermique en décidant d'emblée de relativiser le problème.

Je crois que cette attitude est une grave erreur. Ce n'est pas du tout à la hauteur de l'internet d'aujourd'hui, et la démarche qu'applique le mec est ouverte à tous, aux méchants aussi.

C'est pas ma spécialité, mais je prends ça très au sérieux, car pour d'autres c'est plus qu'une spécialité, c'est leur gagne-pain, et ça paye gros.

Vous êtes au courant qu'aujourd'hui on prend en otage des réseaux entiers avec des demandes de rançon. tu as des ISPs qui se prennent des DDNS de plusieurs gigabits durant quelques minutes, et qui reçoivent ensuite un petit courrier pour payer tant avant que cela ne dure plusieurs jours.

la sécurité ça va devenir très sérieux, et nous ne voyons ici qu'une partie du problème.

Et les mecs qui font du POLA quand ils font du dev d'appli web, pose toi la question de combien ils sont ?

J'ai fait une recherche récemment sur tout développez.com d'outils comme caja ou adsafe, aucune référence ici.

Moi à mon avis, et à voir vos réactions je comprends, on a un sacré retard là-dessus.

En psychologie on parle de dénégation

[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.....