IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Hinault Romaric

149PARTAGES

3  4 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de _skip
Expert éminent https://www.developpez.com
Le 27/03/2012 à 20:59
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...
14  0 
Avatar de MiaowZedong
Membre extrêmement actif https://www.developpez.com
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.
8  0 
Avatar de ProgVal
Membre éclairé https://www.developpez.com
Le 27/03/2012 à 21:55
Citation Envoyé par Hinault Romaric Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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 Voir le message
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.
4  1 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 28/03/2012 à 9:51
Citation Envoyé par Freem Voir le message

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*.
1  0 
Avatar de SurferIX
Membre chevronné https://www.developpez.com
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".
1  0 
Avatar de laerne
Membre éprouvé https://www.developpez.com
Le 27/03/2012 à 21:59
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é !
0  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 27/03/2012 à 23:06
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.
0  0 
Avatar de anthony43
Candidat au Club https://www.developpez.com
Le 27/03/2012 à 23:46
@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...
0  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 28/03/2012 à 0:09
Citation Envoyé par anthony43 Voir le message
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
0  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
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)
0  0