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 !

Linux Foundation initie un nouveau programme
Pour améliorer la sécurité des logiciels open source

Le , par Michael Guilloux

80PARTAGES

9  0 
Mieux vaut prévenir que guérir. Les leaders de l’open source multiplient les efforts pour renforcer la sécurité des logiciels open source, avant qu’ils ne deviennent une cible fréquente pour les pirates.

Le mois dernier, dans le cadre de son projet baptisé Core Infrastructure Initiative (CII), la fondation Linux a fait un examen des logiciels open source Linux Debian afin d’en déterminer ceux qui nécessitent plus d’attention de la part des développeurs du point de vue de la sécurité. L’objectif était de pouvoir ensuite mobiliser les ressources humaines et financières pour renforcer la sécurité de ces projets.

Le CII est en fait un projet qui réunit entreprises de technologie, développeurs et certains acteurs de l’industrie. Tous doivent collaborer pour identifier et financer les projets de logiciels libres et open source essentiels pour le fonctionnement de l’Internet et d’autres grands systèmes d’information qui ont besoin d’une assistance.

Le fait est que de plus en plus de services en ligne utilisés aujourd’hui reposent sur les logiciels open source. Ce qui pourrait donc progressivement attirer l'attention des pirates à la recherche de failles dans la sécurité des logiciels à exploiter. Pour protéger les services en ligne qui reposent sur l’open source, Linux Foundation veut compter sur une équipe dédiée de professionnels de sécurité pour anticiper les éventuels problèmes de sécurité et les corriger.

Dans la poursuite de son objectif de sécurité, le projet Core Infrastructure Initiative a initié un nouveau programme baptisé Badge Program. A travers ce programme axé sur la sécurité, le CII invite la communauté open source à faire des propositions sur les critères à utiliser pour déterminer la sécurité, la qualité et la stabilité des logiciels open source.

Le Badge Program est destiné à encourager les projets de logiciels open source à prendre en considération à la fois la sécurité et la qualité et aider les utilisateurs à savoir quels projets prennent en considération ces différents aspects. Il vise à garantir un « modèle de développement open source sécurisé ». Il permettra de s’assurer que « les nouveaux projets ne dépendent que des projets open source les plus sains, améliorant ainsi notre infrastructure mondiale de l’Internet », explique Emily Ratliff, directeur senior de la sécurité d’infrastructure chez Linux Foundation.

Une première ébauche du projet de critères est disponible sur GitHub et est dirigée par David Wheeler, un expert de l'open source et de la sécurité qui travaille pour l'Institut for Defense Analyses (IDA) et Dan Kohn, un conseiller senior du projet CII.

Le CII a également renforcé son conseil consultatif par deux personnalités imminentes de la cyber-sécurité. Il s’agit d’Adam Shostack, membre du conseil d’examen du BlackHat, et Tom Ritter, directeur de Cryptography Services de CCN Group.

Source : Market Wired, GitHub

Et vous ?

Que pensez-vous des efforts de Linux Foundation pour renforcer la sécurité des projets open source ?

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

Avatar de Goedulf
Membre du Club https://www.developpez.com
Le 19/08/2015 à 23:57
Citation Envoyé par Davidbrcz


Arrêtons d'écrire des logiciels en C, et le sécurité sera mécaniquement augmentée.

Exact, mieux vaudrait un noyau Linux écrit en Visual Basic.
8  4 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/08/2015 à 7:57
Citation Envoyé par BufferBob Voir le message
du coup tu fais quoi avec ? y'a bien le LOGO (et encore ) sinon je vois pas trop quel langage empêche d'écrire dans la mémoire...
C'est fou les développeur C++ qui sont persuadés de tout connaître des autre langages.
Evidement que tous les langages, même le logo manipulent la mémoire. Cela dit, il y a énormément de langages, qui permettent d'utiliser la mémoire via des pointeur ou d'autres mécanisme, tout en imposant un minimum de restriction, ou des contrôles qui permettent une bien meilleure sécurité.

Je te conseille de te renseigner sur le Rust par exemple, qui permet d’empêcher les erreur mémoire tout en permettant un contrôle bas niveau comme le C/C++.

Citation Envoyé par BufferBob Voir le message
qui plus est les systèmes ont depuis plusieurs années vu développer des contre-mesures pour éviter les exploitations, c'est assez standard de nos jours (ASLR, NX, PIE, grsec, propolice et autres canarys etc.), et il semble que ça ait été jugé plus rentable que de troquer C pour un autre langage avec tous les problèmes de rétro-compatibilité que ça aurait engendré
Et malgré ça les exploit lié a une corruption de la mémoire sont de loin les problèmes de sécurités les plus courants sur les grosse applications C/C++.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/08/2015 à 15:56
Citation Envoyé par imikado Voir le message
Vous pensez que IE est écrit en C ?
IE est en C++ il me semble, ce qui n'est pas forcément mieux niveau sécurité non plus, surtout que vu son age, il y a fort a parier qu'il repose fortement sur du code pré C++11.

Citation Envoyé par imikado Voir le message
Idem pour les sites internet, dont nombre d'entre eux souffrent de failles (xss, xsrf, sql injection, null byte...)
Les failles Web et applicatives sont deux domaines relativement distincts.

Un langage plus adapté ne résoudra évidement pas les failles venant de mauvais algorithmes, mais ça devrait pouvoir réduire voire faire complètement disparaitre certaines erreurs classiques, particulièrement pour ce qui est des failles dues à la sécurité mémoire qui comptent parmi les plus courantes et les plus dangereuses en C et C++.

Citation Envoyé par Beanux Voir le message
Comme tu dis, soyons constructif,
Tu as des exemple de langages "sûr" ?
La grande majorité des langages est plus sure que le C et le C++. C'est notamment le cas des langages de plus haut niveau (C#, Java, Go, ...)
Parmi les langages conçus pour être particulièrement sûr au niveau de la gestion de la mémoire, tout en restant de plus bas niveau, on peut citer le vénérable l'Ada, ou le plus récent Rust.

Citation Envoyé par Beanux Voir le message
Tu as des arguments à apporter pour justifier que C est moins sûr ?
Mis à par que ce soit un langage plutôt bas niveau et qu'il y est plus simple de faire des erreurs (donc erreurs provenant du développeur).
Tu as répondu toi même à la question : c'est un langage bas niveau qui n'a aucun garde fou et qui permet facilement de corrompre la mémoire sans s'en rendre compte.

Comme toute les failles, c'est, en effet, des erreurs de programmation, mais il faut prendre en compte que les hommes, même les meilleurs, ne sont pas infaillibles. Tout expert en sécurité sait que concentrer sa sécurité sur la compétence des développeurs, c'est insuffisant. Il y a aussi des outils pour aider a gérer ça mais la complexité du langage fait que ils ne pourront jamais tout garantir non plus.

Même dans les projets le plus surveillés comme le navigateurs, près de la moitié des failles sont liées à la gestion mémoire. Ce n'est pas pour rien que Mozilla a créé Rust, un nouveau langage plus sûr pour travailler sur l’éventuel remplaçant de Gecko.

Citation Envoyé par Beanux Voir le message
Le langage est loin de d’être les premières raisons de l'insécurité du code.
L'erreur est forcément humaine à la base. Si on savait toujours éviter les erreurs, on n'aurait pas de faille, même avec le pire des langages.
Ceci dit comme nul n'est parfait, si le langage peut aider l'humain à éviter de faire certaines erreurs, c'est bon à prendre.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/08/2015 à 16:19
En poursuivant ce raisonnement : pourquoi ne devrait on se sentir moins en sécurité dans une voiture sans ceintures, pare-chocs, airbags, ABS, ... Si l'on conduit correctement, tout cela ne sert a rien non?

Croire que pour une bonne sécurité, il suffit d'avoir des bons développeurs, c'est aller dans le mur, parce que les développeurs ne sont pas des machines. S'il y a besoin de sécurisation, c'est bien justement parce que l'on sait qu'il y aura forcement des erreurs humaines à un moment donné. La sécurité vise a fournir des outils et des méthodes pour prévenir ces l’erreur ou au moins d'en atténuer l'impact.
3  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 20/08/2015 à 9:32
Vous pensez que IE est écrit en C ?

Idem pour les sites internet, dont nombre d'entre eux souffrent de failles (xss, xsrf, sql injection, null byte...)

Le langage ne fait pas tout
3  1 
Avatar de Goedulf
Membre du Club https://www.developpez.com
Le 20/08/2015 à 11:23
Citation Envoyé par Davidbrcz
Essayons d'être constructif :

Le C est un langage de niche qui ne doit être réservé qu'à quelques cas particuliers (composant systèmes bas niveau, systèmes embarqués, code glu entre 2 langages,...).

Un bon paquet de logiciels qu'on utilise tout les jours gagnerait en sécurité et en simplicité à ne pas être écrits en C. Après y'a l'inertie technique, mais quand même...
Plus vite on circonscrira le C aux endroits où il est indispensable, mieux on se portera
Ah pardon je pensais que c'était pour plaisanter alors j'ai feed...
Je ne suis pas sûr qu'on puisse dire aussi facilement que ça que tel language est plus sécurisé que le C, ni même cantonné celui-ci à de l'utilisation purement bas niveau
Comme dit précédemment, on ne peut pas réduire la sécurité au simple choix d'un language, ça se saurait
2  0 
Avatar de Davidbrcz
Rédacteur https://www.developpez.com
Le 20/08/2015 à 20:04
Au profit du C++ ... ?
Non, le langage est devenu bien trop expert only.

Tu as des exemple de langages "sûr" ?
Tu as des arguments à apporter pour justifier que C est moins sûr ?
N'importe quel langage qui interdit une arithmétique des pointeurs et un accès libre à la mémoire.


Le langage est loin de d’être les premières raisons de l'insécurité du code.
utiliser le C pour développer une application hors de son champs d'application, c'est comme la libre circulation des armes à feu. Dans un monde parfait, avec des gens compétents, sérieux et responsables, ca pose pas de soucis. On connait tous la réalité


En quoi changer de langage apporterais une meilleur sécurité ?
  • Heartbleed : accès mémoire foireux
  • Apple : SSL double goto car y'a pas de mécanisme de gestion des erreurs.
  • Et je passe sous silence les buffers overflow que permet le C...


Le C est une source sans fin de bugs exploitables.


C'est comme avec les bugs, c'est pas en changeant de langage qu'ils vont se corriger tous seul.
Les failles proviennes des logiciels que les développeurs convoient, rarement du langage ou du compilateur.
Changer de langage permet de grandement diminuer le risque de bug. Ca corrigera pas une logique applicative foireuse par contre.
2  0 
Avatar de Betameche
Membre habitué https://www.developpez.com
Le 21/08/2015 à 12:21
Sans trop rentrer dans le débat, mais ayant vu l'erreur à plusieurs reprises:

C'est fou les développeur qui sont persuadés de connaître le C++ (humour pour ceux qui en douterait), alors même qu'ils semblent ignorer l'existence de ça bibliothèque standard.
Utiliser std:: et la bonne partie des risques de buffers overflows sont éliminés (il peut y avoir avec une mauvaise utilisation de std::copy). Après je sais bien qu'avec une utilisation un peu à l'arrache des pointeurs on peut facilement faire des erreurs et que ça reste un langage exigeant par rapport à d'autre. Je pointe juste du doigt le fait que beaucoup des erreurs communément imputées aux C++ sont dues à l'utilisation des solutions du C à la place de celles du C++ (qui sont pourtant souvent plus simples). Et puis même en C, éviter les BO est plus une question de rigueur que de génie.

Arrêtons de mélanger C et C++ comme un seul et même langage.

Et quitte à me faire moinser, j'ajouterai que les VMs ne sont pas exemptes de tous défauts non plus (par rapport aux remarques sur JAVA et C#). Et l'utilisation d'un "mauvais" langage pour un projet n'est pas limité aux C, et le choix du langage n'est pas aussi trivial que ça (sinon ce débat n'existerait même pas).
3  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/08/2015 à 15:01
Citation Envoyé par Betameche Voir le message
Utiliser std:: et la bonne partie des risques de buffers overflows sont éliminés. Arrêtons de mélanger
La stdlib de C+11 c'est mieux que rien, mais c'est très loin d'être suffisant pour faire de C++ un langage sur.
De plus l'héritage C est inamovible et c'est bien le premier problème. Son utilisation généralement plus naturelle que celle de la stdlib et la frontière entre ce qu'il est sur et ce qui ne l'est pas est loin d'être évidente.

Citation Envoyé par Betameche Voir le message
Et quitte à me faire moinser, j'ajouterai que les VMs ne sont pas exemptes de tous défauts non plus (par rapport aux remarques sur JAVA et C#).
Ma remarque visait les langages et non les VM, même si les langages conçus pour VM prennent a ma connaissance tous en compte au moins la sécurité mémoire. Beaucoup de langages sans VM (Go, Haskell, Ada, Rust, ...) empêchent tout de même la plupart, voire la totalité des erreurs qui pourraient conduire à une corruption mémoire.

Après en effet, même les langages les plus sûrs comme Ada ou Rust, peuvent abusés s'ils sont particulièrement mal utilisés, mais leur conception est faite pour minimiser au maximum le risque, là ou le C++ doit composer avec son héritage qui ignore totalement la problématique.
2  0 
Avatar de Davidbrcz
Rédacteur https://www.developpez.com
Le 20/08/2015 à 2:16
Citation Envoyé par Goedulf Voir le message
Exact, mieux vaudrait un noyau Linux écrit en Visual Basic.
Essayons d'être constructif :

Le C est un langage de niche qui ne doit être réservé qu'à quelques cas particuliers (composant systèmes bas niveau, systèmes embarqués, code glu entre 2 langages,...).

Un bon paquet de logiciels qu'on utilise tout les jours gagnerait en sécurité et en simplicité à ne pas être écrits en C. Après y'a l'inertie technique, mais quand même...
Plus vite on circonscrira le C aux endroits où il est indispensable, mieux on se portera.
5  4