Plus d'un tiers des bibliothèques open source ont des vulnérabilités connues
80% du code des applications repose sur celles-ci

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux


 Discussion forum

Le , par Hinault Romaric, Responsable Actualités
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 ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de tchize_ tchize_
http://www.developpez.com
Expert Confirmé Sénior
le 28/03/2012 10:06
Citation Envoyé par _skip  Voir le message
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 (exécution arbitraire d'applications natives sur une machine faisant tourner du struts 2)
Avatar de SurferIX SurferIX
http://www.developpez.com
Membre émérite
le 28/03/2012 11:03
Citation Envoyé par Hinault Romaric  Voir le message
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"
- 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".
Avatar de MiaowZedong MiaowZedong
http://www.developpez.com
Membre Expert
le 28/03/2012 11:24
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.
Avatar de tchize_ tchize_
http://www.developpez.com
Expert Confirmé Sénior
le 28/03/2012 13:57
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.
Avatar de _skip _skip
http://www.developpez.com
Expert Confirmé Sénior
le 28/03/2012 14:30
Citation Envoyé par tchize_  Voir le message
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.

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.
Avatar de tchize_ tchize_
http://www.developpez.com
Expert Confirmé Sénior
le 28/03/2012 14:41
Citation Envoyé par _skip  Voir le message
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.

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
Avatar de anthony43 anthony43
http://www.developpez.com
Invité de passage
le 28/03/2012 20:08
Citation Envoyé par tchize_  Voir le message
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_  Voir le message
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...
Avatar de tchize_ tchize_
http://www.developpez.com
Expert Confirmé Sénior
le 28/03/2012 23:27
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 :/
Avatar de anthony43 anthony43
http://www.developpez.com
Invité de passage
le 29/03/2012 21:57
Citation Envoyé par tchize_  Voir le message
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)
Avatar de freddd2 freddd2
http://www.developpez.com

le 30/03/2012 23:34
Ce sera surement mieux sur le cloud avec microsoft ....
Avatar de Etre_Libre Etre_Libre
http://www.developpez.com
Membre chevronné
le 01/04/2012 5:27
Citation Envoyé par tchize_  Voir le message
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.

Je crois que ton point de vue est partagé par d'autres aussi, même si j'admets que je ne suis pas vraiment d'accord, je peux comprendre pourquoi la décision est prise.

Exemple : Un routeur Cisco RV042 V3 (firmware commun avec les RV016 et RV082).

Le dernier firmware date de janvier 2012 : superbe dirait-on ?

Mais en fait, quand j'ai fait la demande du firmware open source pour le modifier, on m'a indiqué qu'il fallait un Fedora 6... et ce n'est pas une blague.

Au départ j'ai bien sûr essayé avec un Fedora 16, pas moyen de compiler, les librairies avaient trop changé.

Je ne sais pas à quel degré c'est fait, mais Cisco semble corriger des failles de sécurité etc... donc je suppose qu'ils patchent uniquement ce qui est découvert ou critique, le strict minimum ?
Offres d'emploi IT
Consultant junior AMOA H/F
CDI
EXPERIS IT - Ile de France - Paris (75000)
Parue le 07/07/2014
Ingénieur qa pour applications web et mobile
CDI
MOBISKILL - Ile de France - Paris (75000)
Parue le 17/07/2014
Ingénieur développement (h/f)
CDI
Kacileo - Ile de France - Paris (75000)
Parue le 11/07/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula