Plus d’un tiers des bibliothèques open source ont des vulnérabilités connues

Plus d’un tiers des bibliothèques open source ont des vulnérabilités connues
80% du code des applications repose sur celles-ci, selon un rapport de Sonatype

De nombreuses entreprises utilisent des composants et des bibliothèques open source contenant des vulnérabilités pour la conception de leurs applications, selon un rapport mené conjointement par l’éditeur de logiciels Sonatype et la firme de sécurité Aspect Security.

L’entreprise Sonatype fournit un gestionnaire de version centralisé, hébergé pour plus de 300 000 bibliothèques qui sont téléchargées pour des applications ou des solutions open source. Près de 4 milliards de requêtes sont effectuées par an sur ces composants.

Le rapport basé sur 31 bibliothèques populaires téléchargées au cours des 12 derniers mois a révélé que plus d’un tiers des 1 261 versions de ces composants avaient des vulnérabilités connues.

Ces vulnérabilités sont couramment ignorées par les développeurs, surtout qu’il manque un système d’alerte sur les failles et les patchs. « 80% du code dans les applications de nos jours provient des bibliothèques. Le risque de vulnérabilité dans ces composants est largement ignoré et sous-estimé » explique Jeff Williams, directeur de recherche pour Aspect Security.

Les bibliothèques vulnérables les plus téléchargées sont entre autres Google Web Toolkit, Apache Xerces, Spring MVC et Struts 1.x.

Les types de vulnérabilités découvertes dans les bibliothèques open source sont très variables, allant des failles pouvant permettre l’exécution du code arbitraire, aux failles pouvant compromettre les données et permettre à un pirate distant d’accéder à celles-ci.

Ce rapport est à prendre néanmoins avec modération, car une étude publiée par Coverity le mois dernier révélait que le code source des applications open source était d’une qualité égale, voire meilleure que celle des applications propriétaires.


Source : Le rapport téléchargeable après inscription


Et vous ?

:fleche: Qu'en pensez-vous ?

Apache Xerces nommé ci-dessus est un parser sax XML, il est bien possible que 80% des utilisations qui en sont faites ne présente aucune vulnérabilité.

Bref à mon sens, un gros chiffre comme ça ne veut pas dire grand chose sans situation concrète, est-ce que ces vulnérabilités sont tranquillement exploitables sans autres sur le net ou celles-ci dépendent-t-elles d'un concours de circonstances super fumeux qui a presque aucune chance de se produire?

Peu de précision, et on dirait une manière éventuellement de vendre du service à voir le formulaire sur la source...

On peut rajouter un exemple actuel, celui de µClibc, librairie C, utilisée dans les freebox, live box, etc. et qui ne sait pas remettre à l'heure d'été nos box...

Citation:

---

Envoyé par Hinault Romaric

L’entreprise Sonatype fournit un gestionnaire de version centralisé, hébergé pour plus de 300 000 bibliothèques qui sont téléchargées pour des applications ou des solutions open source. Près de 4 milliards de requêtes sont effectuées par an sur ces composants.

Le rapport basé sur 31 bibliothèques populaires téléchargées au cours des 12 derniers mois a révélé que plus d’un tiers des 1 261 versions de ces composants ont des vulnérabilités connues.

---

À noter qu'il s'agit de 31 bibliothèques hébergées par Sonatype ; service dont je n'ai personnellement jamais entendu parler. En même temps, ils ne proposent que de l'hébergement pour Apache Maven, qui est un gestionnaire de version pour Java ; et je ne fréquente pas ce milieu, hormis pour Android.
Ajoutons, pour la petite histoire, qu'ils utilisent GitHub.

Citation:

---

Envoyé par Hinault Romaric

Ces vulnérabilités sont couramment ignorées par les développeurs, surtout qu’il manque un système d’alerte sur les failles et les patchs.

---

Et les bugtrackers, ça sert à quoi ?
Toujours pour la petite histoire : Sonatype propose un service de gestion des failles de sécurité. Pas génial comme publicité...

Citation:

---

Envoyé par Hinault Romaric

Ce rapport est à prendre néanmoins avec modération, car une étude publiée par Coverity le mois dernier révélait que le code source des applications open source était d’une qualité égale, voire meilleure que celle des applications propriétaires.

---

Étude qui avait également l'air assez vague.

Citation:

---

Envoyé par Hinault Romaric

:fleche: Qu'en pensez-vous ?

---

En plus de se restreindre à un langage en particulier, et de nous présenter plein de jolis chiffres.
De plus, l'étude est ici plus ou moins présentée comme opposant bibliothèques open sources et non open sources, alors que ce n'est à l'origine pas le cas (je n'ai pas lu le rapport ; je n'ai pas envie de m'inscrire).
En plus, j'ai du mal à comprendre le concept de « vulnérabilité connue », mais dont ceux-ci ne sont pas « alertés ».

Citation:

---

Envoyé par mtranchant

On peut rajouter un exemple actuel, celui de µClibc, librairie C, utilisée dans les freebox, live box, etc. et qui ne sait pas remettre à l'heure d'été nos box...

---

Sisi, elle sait remettre à l'heure. C'est seulement que Free et Orange ont eu la flemme d'intégrer le patch qui a été soumis l'an dernier.

Si Coverty et Sonatype ont toutes les deux raisons, ça veut dire qu'un tiers ou plus de toutes les bibliothèques (open source ou pas) ont une vulrabilité connue (peut non dévoilé)…

De toutes façon je crois qu'elles ont toutes les deux tords… sur leur manière de faire des stats.
On manque clairement de statisticiens dans notre société !

Il faut voir aussi dans quelles mesures ces failles sont exploitables. Tu n'effectue pas le même niveau de test entre une application visible de millions de personnes et, comme c'est selon moi la majorité des développements, une application destinée à servir sur un serveur interne d'entreprise sur lequel il faut se logguer avant de pouvoir faire quoi que ce soit.

@ProgVal
>31 bibliothèques hébergées par Sonatype ; service dont je n'ai personnellement jamais entendu parler
Sonatype est la compagnie qui gere aujourd'hui Maven Central, le plus grand repo de binaires (java et scala aussi maintenant) au monde; accessible par Maven/Ivy/Gradle

>Ajoutons, pour la petite histoire, qu'ils utilisent GitHub.
ok et alors ?

> Toujours pour la petite histoire : Sonatype propose un service de gestion des failles de sécurité. Pas génial comme publicité...
Ben si justement ; ils ont les stats de maven central, et ils analysent les librairies (ils les soumettent à des bases de vulnérabilités connues) qui y sont hébergées : ils sont capables de te dire si ton client/employeur (via l ip de l'entreprise) utilise des librairies avec des vulnérabilités critiques et propose plein d'outils (service payant, faut bien vivre) pour notifier les DSI que leurs développeurs intègrent potentiellement des lib désuètes ou ayant des vulnérabilités connues


Maintenant que des libs open sources présentent des vulnérabilités, c'est assez normal, vu le nombre qu'il existe; cependant, de ma (courte) expérience, le code propriétaire est souvent bien plus vulnérable/ peu performant / mal désigné/ peu testé que le code open source car après tout, personne vient mettre son nez dedans pour l'améliorer et le critiquer...

Citation:

---

Envoyé par anthony43

ils sont capables de te dire si ton client/employeur (via l ip de l'entreprise) utilise des librairies avec des vulnérabilités critiques et propose plein d'outils (service payant, faut bien vivre) pour notifier les DSI que leurs développeurs intègrent potentiellement des lib désuètes ou ayant des vulnérabilités connues

---

Mouais, bof, si comme la pluspart des boites, t'as un nexus interne, ils vont pas voir beaucoup de requêtes. Plus, pour la plupart des librairies répandue, tu verra chez moi des requetes qui vont de la version 1.0 à 5.0 avec tous les intermédiaires possibles. Pourquoi? Bien qu'on utilise la dernière version (quand c'est le cas) les dépendances de compilation utilisent bien souvent des version antérieures.

Donc le rapport serait bourré à 99% de faux positifs :aie:

Petite correction:
Sur l'encart publicitaire (on peut pas appeler ça autrement, si encore il y avait un ou deux noms de cités, avec ou sans failles q), c'est écrit 26%, c'est plus proche de 1/4 que d'1/3.

Pour le reste: bof.
"Etude" limitée à un langage seul (qui plus est pour lequel je n'ai aucun amour).
Présentation de l'étude qui ressemble à un encart publicitaire.
Etude par un repo dont je n'ai jamais entendu parler (sûrement parce que moi je java...).

Et puis bon, en java, on redonne volontairement un certain nombre de contrôles au langage, tels que la gestion de la mémoire (dans une certaine mesure).
Etrangement, j'ai envie de dire que si on peut injecter du code dans une appli, c'est p'tet la faute au langage, dans ce cas. Puisque le programmeur n'est pas censé s'occuper de ce genre de choses.
En C, C++, ASM et autres, la faute reviendrai au développeur, mais la...

En outre, ils ne citent même pas un nom de faille/vulnérabilité. Comment peut-on avoir ne serait-ce qu'une idée vague de ce qu'ils ont trouvé... perso, ça me donne pas envie de m'inscrire pour recevoir leur machin.

Citation:

---

Envoyé par Freem

Et puis bon, en java, on redonne volontairement un certain nombre de contrôles au langage, tels que la gestion de la mémoire (dans une certaine mesure).
Etrangement, j'ai envie de dire que si on peut injecter du code dans une appli, c'est p'tet la faute au langage, dans ce cas. Puisque le programmeur n'est pas censé s'occuper de ce genre de choses.
En C, C++, ASM et autres, la faute reviendrai au développeur, mais la...

---

Vu la nature de java, injecter du code depuis l'extérieur en passant par une librairie ça me paraît un peu chaud. Je pense qu'on parle surtout, puisque des frameworks web sont impliqués, d'injection SQL ou XSS.

Ca élargit encore le débat sur les "failles" mentionnées sur lesquelles nous n'avons aucun détail quant à la part de responsabilité du développeur dans son exploitation. On peut en plus se demander où la barre a été placée entre *faille* et *risque potentiel*.

Citation:

---

Envoyé par _skip

Vu la nature de java, injecter du code depuis l'extérieur en passant par une librairie ça me paraît un peu chaud.

---

Tout dépend des librairies impliquées.

Des librairies comme JSF, struts, etc utilisent fortement de l'introspection. Résultat, que se passe-t-il si j'arrive à rediriger JSF ou Struts vers Runtime.exec() par introspection?

Des librairies comme aspectj interagissent avec le classloader, elles sont un facteur de risque à prendre en compte.

Des librairies hibernate ou DAO risquent l'injection sql évidement

et des librairies de sécurité généralistes courent le risque d'avoir un trou laissant quelqu'un se faire passer pour un admin.

Les failles mentionnées dans le document font froid dans le dos 8O (exécution arbitraire d'applications natives sur une machine faisant tourner du struts 2)

Citation:

---

Envoyé par Hinault Romaric

Plus d’un tiers des bibliothèques open source ont des vulnérabilités connues
80% du code des applications repose sur celles-ci, selon un rapport de Sonatype

---

Je vois deux problèmes :
- "selon un rapport de Sonatype" :D
- bibliothèques open source.

Il faut être réaliste et honnêtement, quel pourcentage de bibliothèques non open source ont des vulnérabilités inconnues (ce qui, techniquement parlant, est pire) ?

Il suffit de voir Microsoft, et toutes les mises à jours, avec ses bulletins de sécurité et les failles considérées comme critiques. Ce sont des failles dite "zéro day", c'est à dire qu'elles sont immédiatement exploitables. Microsoft ne divulgue les problèmes qu'après avoir fait les mises à jour, mais si un pirate les trouve avant Microsoft ?

Et surtout, pour en revenir au pourcentage, même si on critique l'open source, il faut rester lucide : je pense qu'il y a le même pourcentage, voire pire, dans le monde "closed source".

Il me semble que cela porte avant tout sur l'utilisation de versions obsolètes des frameworks, comportant des failles connues (corrigées dans les versions plus récentes).

Là c'est un mal connu: il faut toujours utiliser les dernières versions dans l'open source (dans le propriétaire c'est plus compliqué, la montée en version sert à faire payer à nouveau le client). Il est extrèmement courant que les malwares se répandent en exploitant des failles déjà corrigées, en profitant de la stupidité d'organisations qui n'ont pas fait leurs mises à jour. Il est vraiment plus que temps de faire comprendre en entreprise qu'un patch critique est critique, point.

l'idéal selon moi serait que des outils comme maven puissent te faire un "potential vulnerability assessement" sur base des versions présentes dans ton .war au final. Parce que si, pour chaque application développée en interne sur des projets de 3 à 4 mois, je dois me coltiner de suivre les update de 80 librairies et, toutes les semaines, faire une mise à jour pour utiliser la dernière version de X ou Y, a bout de 4 projet, mon équipe est à l'arrêt.



Et faire une mise à jour de sécurité, ce n'est souvent possible en temps raisonnable que si on reste dans la même révision mineure. Passer à la majeure suivante, c'est parfois beaucoup de boulot. API incompatibles, nouveaux fichiers de configurations, repasser toutes les batteries de test quality control.
Enfin, quand on a un mix de closed source et d'open source, que le closed source n'est plus maintenu (ou coute trop d'énergie à migrer) et n'est pas compatible avec la nouvelle version de xerces ou de xml-api, on est vite dans un cul de sac.

Tout ça ça coute énormément d'argent. Alors oui, souvent, on reste avec les ancienne librairies et on assume les risques. Tout est une question de moyen et du rapport entre les moyens et les risques.

Citation:

---

Envoyé par tchize_

Tout dépend des librairies impliquées.

Des librairies comme JSF, struts, etc utilisent fortement de l'introspection. Résultat, que se passe-t-il si j'arrive à rediriger JSF ou Struts vers Runtime.exec() par introspection?

Des librairies comme aspectj interagissent avec le classloader, elles sont un facteur de risque à prendre en compte.

---

Mais tu introspectes des bean de ton propre domaine normalement, comment une personne externe pourrait forcer ton application à introspecter Runtime plutôt que MonBeanDTO? Je dis pas que c'est impossible mais ça me paraît clairement chaud de détourner extérieurement ce mécanisme.

Citation:

---

Des librairies hibernate ou DAO risquent l'injection sql évidement

---

Pas plus, sinon moins que du JDBC standard... Sachant que la plupart des ORM utilisent des peparedStatement.

Là aussi le problème c'est qu'il manque les use case pour qu'on puisse juger.

Citation:

---

Envoyé par _skip

Mais tu introspectes des bean de ton propre domaine normalement, comment une personne externe pourrait forcer ton application à introspecter Runtime plutôt que MonBeanDTO? Je dis pas que c'est impossible mais ça me paraît clairement chaud de détourner extérieurement ce mécanisme.

---

Cette vulnérabilité a frappé struts 2 et a été qualifié de "facile à mettre en oeuvre", quelle que soit l'application concernée d'ailleurs. Spring a une vulnérabilité similaire où tu peux lui faire interpréter un EL quelconque à partir d'une requête http.

Citation:

---

Pas plus, sinon moins que du JDBC standard... Sachant que la plupart des ORM utilisent des peparedStatement.

Là aussi le problème c'est qu'il manque les use case pour qu'on puisse juger.

---

Bien sûr, mais le fait est que si tu utilise hibernate et que suite à une erreur de codage ça pourrait arriver mais tu n'en sais rien, ça nécessite que tu check régulièrement. Et, cf mon poste précédente, en général, tu n'en a pas les moyens :)

Citation:

---

Envoyé par tchize_

Mouais, bof, si comme la pluspart des boites, t'as un nexus interne, ils vont pas voir beaucoup de requêtes

---

pas besoin de faire 100 fois la même requête, une seule fois (via ton repo manager interne) et ils le savent que t'utilisent log4j 1.0

Citation:

---

Envoyé par tchize_

l'idéal selon moi serait que des outils comme maven puissent te faire un "potential vulnerability assessement" sur base des versions présentes dans ton .war au final. Parce que si, pour chaque application développée en interne sur des projets de 3 à 4 mois, je dois me coltiner de suivre les update de 80 librairies et, toutes les semaines, faire une mise à jour pour utiliser la dernière version de X ou Y, a bout de 4 projet, mon équipe est à l'arrêt.

---

çà tombe bien, çà existe, et çà s'appelle sonatype insight, mais faut passer à la caisse d'abord.

Cette étude, elle sert juste à prouver que la majorité des utilisateurs (pas tous) de bibliothèques java font justement pas attention aux failles de sécurité et que eux autres (Sonatype) fournissent un service qui pourrait rendre service à ces personnes là.

pour info BlackDuck software propose un service à peu près similaire...

oui, mais j'aurais plutot espéré un truc intégré à maven. Genre tu met ta librairie dans maven, le jour ou t'as des security issue, tu notifie aussi dans maven tes security issue et du coup un plugin maven pourrait les lister. Après tout, si tu fais l'effort de mettre tes jar dans un repo maven public,ça devrait pas te couter plus de faire aussi l'effort d'y mettre tes notifications de sécurités :)

De la même manière que t'as un .pom avec des <licence> dedans, tu pourrais avoir un .issue avec des <security-issue> dedans :)

Le problème avec sonatype insight c'est que non seulement il faut passer à la caisse (soit), mais leur politique de prix est tout sauf transparente :/

Citation:

---

Envoyé par tchize_

oui, mais j'aurais plutot espéré un truc intégré à maven. Genre tu met ta librairie dans maven, le jour ou t'as des security issue, tu notifie aussi dans maven tes security issue et du coup un plugin maven pourrait les lister. Après tout, si tu fais l'effort de mettre tes jar dans un repo maven public,ça devrait pas te couter plus de faire aussi l'effort d'y mettre tes notifications de sécurités :)

---

c'est 1 bonne idée; 1 truc collaboratif en sorte; il faudrait qu'il y aie aussi une sorte de niveau de confiance ou des super utilisateurs pour valider; comme wikipedia...
faudrait 1 plugin dans maven et dans nexus aussi d'ailleurs...

que le tarif de insight soit pas transparent, c'est souvent le cas dans les services dans le monde logiciel (mis à part les licences logicielles)

Ce sera surement mieux sur le cloud avec microsoft ....