Plus d'un tiers des bibliothèques open source ont des vulnérabilités connues
80% du code des applications repose sur celles-ci
Le 2012-03-27 20:21:52, par Hinault Romaric, Responsable .NET
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 ?
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 ?
-
_skipExpert éminentApache 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...le 27/03/2012 à 20:59 -
MiaowZedongMembre extrêmement actifIl 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.le 28/03/2012 à 11:24 -
ProgValMembre éclairéÀ 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.
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é...
Étude qui avait également l'air assez vague.
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 ».
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.le 27/03/2012 à 21:55 -
_skipExpert éminentVu 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*.le 28/03/2012 à 9:51 -
SurferIXMembre chevronné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".le 28/03/2012 à 11:03 -
laerneMembre éprouvé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é !le 27/03/2012 à 21:59 -
tchize_Expert éminent séniorIl 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.le 27/03/2012 à 23:06
-
anthony43Candidat au Club@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...le 27/03/2012 à 23:46 -
tchize_Expert éminent séniorMouais, 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 positifsle 28/03/2012 à 0:09 -
tchize_Expert éminent séniorTout 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) le 28/03/2012 à 10:06