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 !

Les failles de sécurité doivent-elles être rendues publiques ?

Le , par Hinault Romaric

5PARTAGES

7  0 
Pour certaines entreprises, les failles de sécurité sur les produits doivent être rendues publiques afin de mettre la pression sur les éditeurs de ces produits pour créer des correctifs afin de protéger les utilisateurs. D’autres, par contre, estiment que procéder ainsi expose plus les utilisateurs, car la faille pourrait être exploitée par des pirates avant la sortie d’un correctif.

En début de ce mois, Microsoft s’était notamment insurgée contre Google pour la publication des failles de sécurité dans Windows, dont un correctif n’était pas encore disponible.

Le programme « Google Project Zero » de Google permet à ses experts en sécurité de répertorier des failles de sécurité dans des applications. Lorsqu’une vulnérabilité est enregistrée, une notification est envoyée à l’éditeur de la solution touchée, et la faille est divulguée publiquement 90 jours après, qu’un correctif soit disponible ou non.

Google suppose que la marge de 90 jours est suffisante pour permettre aux éditeurs des produits affectés de créer et publier un correctif. Passé ce délai, on pourrait donc considérer que l’éditeur accorderait moins d’importance à la sécurité de ses utilisateurs.

De plus, tant que la faille n’est pas publique, l’éditeur n’est pas inquiet et préfère investir dans ce qui est plus urgent plus lui : mettre sur le marché de nouveaux produits afin d’augmenter son revenu. De ce fait, une faille de sécurité connue peut demeurer plusieurs années sans correctif. Pourtant, le fait qu’elle ne soit pas publique ne signifie pas pour autant qu’elle n’est pas exploitée par un pirate.

Linus Torvalds, père du noyau Linux, s’est aligné derrière Google lors d’une séance de questions/réponses à l’occasion de la conférence « Linux.conf.au ». « Je crois que les problèmes de sécurité doivent être rendus publics. Il y a des personnes qui soutiennent et ont soutenu pendant des décennies que vous ne devez jamais parler publiquement des problèmes de sécurité, parce que cela peut aider les chapeaux noirs [N.D.L.R, les pirates]. Je pense que vous devez aboutement divulguer les failles, et vous devez le faire dans un délai raisonnable », a affirmé Linus Torvalds.




Celui-ci prend pour exemple la liste de diffusion du noyau Linux, qui est assez réactif dans le traitement des failles de sécurité. « Le délai sur la liste de sécurité du noyau est de cinq jours ouvrables. Certaines personnes pensent que c’est un peu extrême. Dans d’autres projets, le délai est d’un mois ou deux. Mais, c’est encore mieux que des années et des années de silence », explique celui-ci.

Microsoft, de son côté, plaide plutôt une action de façon concertée. Ainsi, les détails sur une faille ne devraient être publiés qu’après la disponibilité d’un correctif. La firme défend son point de vue en mettant en avant le fait que lorsque le secret est gardé sur une faille, le risque d’exploitation de celle-ci est moins élevé, et donc les utilisateurs sont plus en sécurité.

Et vous ?

Etes-vous pour ou contre la divulgation des failles, même si un correctif n’est pas disponible ? Pourquoi ?

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

Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 26/01/2015 à 13:00
Bonjour,

Je pense qu'il est nécessaire de publier les failles au bout d'un délai fixe, car c'est le seul moyen de forcer un peu la main aux éditeurs récalcitrants pour qu'il sortent des correctifs.

Après, concernant les positions respectives :
Microsoft, comme d'autres entreprises, est connue pour ne pas être spécialement rapide dans la correction de bugs connus, et il est donc logique qu'ils soient plutôt opposés à cette stratégie.
L'équipe du kernel Linux, comme d'autres également, est connue pour sa rapidité à publier les correctifs, et donc là encore sa position est parfaitement logique.

Après, est-ce que c'est "juste de la désorganisation" pour les entreprises lentes ? Si je pourrai le croire pour une Startup, je ne peux y croire pour Microsoft, pour qui il s'agit donc d'une stratégie. Maintenant, il peut se révéler que certaines stratégies ne soient pas bonnes sur 20 ou 30 ans.
12  1 
Avatar de Betameche
Membre habitué https://www.developpez.com
Le 26/01/2015 à 18:58
RogerBower, tes messages prouvent que tu n'as pas saisi la problématique. Il y a deux trois chose à changer dans ton exemple:

Pour commencer tu n'est pas le propriétaire de la voiture, mais le constructeur et concessionnaire qui l'es vend. Maintenant disons que Google est un de tes client et qu'il a de grosse exigence en matière de sécurité, il va donc essayer de voir si ses nouvelles voitures sont fiables. De la il découvre que le système de fermeture des portières est défaillantes, il te prévient donc pour que tu puisse faire les modifications qui s'imposent. Mais voila, au bout de trois mois leurs portières et celles de tous les autres utilisateurs, qui pensent eux qu'elles fonctionnent parfaitement, n'ont pas été améliorée. (à ce stade là, on voit que faire des parallèles entre des biens physiques et numériques est un peu bancal puisque changer des portières c'est pas aussi simple que de balancer un patch)

C'est à partir de ce constat, que Google décide de prévenir l'ensemble des utilisateurs, que n'importe qui peut rentrer dans leur voiture, et que toi, vendeur de ces voitures, tu t'en branle car tu es au courant depuis un trimestre et t'as rien fait !

Et quitte à être honnête, il y a pas besoin de trois mois pour corriger une faille de sécurité (surtout pour microsoft), Google à même du prendre en compte le temps de propagation du correctif dans le calcul de ces trois mois !

J'ajouterai, que pendant ces 90 jours, il y a sans doutes un mec moins bien intentionné qui a découvert la même faille et à pu l'exploiter sans problème.
10  1 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 27/01/2015 à 9:57
Citation Envoyé par Sodium Voir le message
D'un côté, j'estime que 90 jours est un délai plus que raisonnable pour réparer des failles potentiellement dangereuses pour l'utilisateur.
D'un autre côté, j'ai du mal à y voir autre chose qu'un gros coup de pub pour Google qui se présente en grand défenseur de l'intérêt des utilisateurs alors que les failles de sécurité d'Androïd font régulièrement l'actualité.
A partir du moment où Google s'impose également ce même délais de 90 jours pour corriger les failles d'Android, je n'y vois aucun problème.
En fait, pour une fois, j'adhère assez bien au discours de Google sur ce sujet qui ne critique en rien le fait qu'il y ait des failles dans les autres systèmes et softs à conditions qu'elles soient corrigées rapidement.
Il n'y a pas de double discours comme d'autres peuvent l'avoir.
Là, c'est assez clair.
Toutes failles doit être corrigées dans les délais le plus court possible à partir du moment où elles sont connues.
Cela s'applique autant à Google qu'aux autres.
Et Google le met bien en oeuvre au travers des hackatons et autres événements de ce type
6  0 
Avatar de psychadelic
Expert confirmé https://www.developpez.com
Le 26/01/2015 à 13:39
Si on veut vraiment parler de sécurité, le fond du problème est tout autre.

Pendant trop longtemps, la sécurité des systèmes était une chose complètement ignorée.

Et encore aujourd’hui, pour les nouveaux développements, les programmeurs n’ont qu’une idée très vague de l’incidence de leur manière de coder sur la sécurité de leur produit.

Tant qu’on restera dans cette logique, les hackeurs-pirates auront des beaux jours devant eux.

Alors perso, je suis pour qu’on rende public les failles sécurité, et même qu’on réduise le délai des 90 jours.

Parce que jusqu'à présent, les décideurs ne prennent toujours pas ce problème au sérieux.

Par exemple, j’aimerai bien savoir si aujourd’hui, les équipes sont capables de concevoir des tests unitaires uniquement dédiés à la sécurité, et quel est la part du budget qui y est allouée ?
5  1 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 26/01/2015 à 16:32
90 jours c'est à la fois long et court.

C'est long, parce que cela fait quand même 3 mois à un "chapeau noire" pour exploiter allègrement la faille.
Et encore, 3 mois c'est un minimum: si on a découvert cette faille c'est peut être parfois qu'elle est déjà exploitée depuis quelque temps.
Et donc, si un patch est délivré avant les 90 jours, il faut que la faille soit largement publiée (et pas que par l'éditeur) pour inciter tout les utilisateurs à appliquer le correctif.

Mais c'est aussi court, 3 mois.
Le temps de trouver la zone du système en cause, de l'associer à une équipe, que celle ci l'étudier, qu'elle réalise un patch et qu'elle le valide ....
.... et le temps file vite

Par contre, je verrais bien une solution un peut hybride.
Que 90 jours soit une valeur par défaut mais que l'éditeur puisse demander un délai supplémentaire pour corriger la faille.
Dans certain cas, les 3 mois permettrons d'identifier clairement le problème, mais cela peux nécessiter 1 ou 2 mois de plus pour bien vérifier la justesse du patch.

Par contre, si l'éditeur ne dit rien, c'est qu'il s'en fou de la sécurité de ses utilisateurs et alors faut publier la faille.
Les utilisateurs peuvent alors trouver un palliatif (via un réglage plus paranoïaque de leur système informatique par exemple) pour se prémunir.
Et en plus, l'éditeur sera alors bien identifier comme un "je-m'en-foutisme" de la sécurité et c'est bien fait pour lui.

Et puis, on verra bien le temps moyen de correction pour chaque faille et leur fréquence.
A chacun alors de se faire son opinion sur la confiance sécuritaire de tel ou tel système.
4  0 
Avatar de Pierre GIRARD
Expert éminent https://www.developpez.com
Le 28/01/2015 à 20:03
Citation Envoyé par Hinault Romaric Voir le message
...Celui-ci prend pour exemple la liste de diffusion du noyau Linux, qui est assez réactif dans le traitement des failles de sécurité. « Le délai sur la liste de sécurité du noyau est de cinq jours ouvrables. Certaines personnes pensent que c’est un peu extrême. Dans d’autres projets, le délai est d’un mois ou deux. Mais, c’est encore mieux que des années et des années de silence », explique celui-ci....
Et vous ?

Etes-vous pour ou contre la divulgation des failles, même si un correctif n’est pas disponible ? Pourquoi ?
Je continue à dire que si ça n'est pas fait en trois mois, c'est que le priorité de l'éditeur n'est pas dans la correction des failles. Dans ces conditions : Un peu de pression ne peut pas faire de mal.

Heureusement que Linus Torvald ne demande pas 5 jours à µSoft pour corriger ses failles comme pour le noyau Linux.
5  1 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 30/01/2015 à 11:05
Citation Envoyé par GrandFather Voir le message
On pourrait imaginer une action un peu moins radicale et plus graduelle : informer d'abord l'éditeur, comme c'est fait actuellement, et 90 jours après informer de l'existence de la faille et de sa gravité si celle-ci n'a pas encore été corrigée, mais sans donner d'indications techniques trop précises qui permettraient son exploitation. Et, à l'issue d'un nouveau délai (30 jours ?), si celle-ci n'est toujours pas corrigée, là tout rendre publique.
Sans vouloir être méchant, si 90 jours n'ont pas suffi pour corriger la faille, je ne vois pas en quoi 30 de plus permettraient quoi que ce soit.
4  0 
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 26/01/2015 à 15:28
Citation Envoyé par M_Makia Voir le message
Cependant en rendant publique une faille non corrigée il ne faut pas oublié que les principales victimes sont les utilisateurs.
Il n'y a pas que Mme Michu qui utilise son ordinateur, il y a aussi des entreprises qui sont censées avoir des services informatiques compétents.

Prenons un exemple :
Le 01/01/2014, un chercheur trouve une faille sur le serveur web IIS. Il communique l'info a Microsoft.
le 01/04/2014, Microsoft n'ayant pas sorti de patch, le chercheur publie l'information. Ce même jour, l'entreprise A qui héberge ses serveurs sous IIS en prend connaissance, et se rend compte que oui, elle est dans ce cas, mais qu'elle peut se passer du module impacté sans mettre à mal son site, ce qu'elle fait.

L'entreprise est tranquille quelques jours seulement après la publication, du moins si elle fait son boulot, et n'est donc vraiment vulnérable que quelques jours, entre la date de publication et le contourenement mis en place. Je trouve que c'est mieux que de fermer les yeux en disant "bof, si un chercheur l'a trouvée, c'est pas grave, il devait être le seul de toute manière".

Et si le problème se pose sur un logiciel grand publique ? Peut-être que cela devrait amener le grand-public à chercher d'autres solutions. Personnellement, je ne fais pas confiance à la plupart des OS actuels pour assurer la sécurité d'un poste de travail (ni Windows, ni Linux), donc je me protège par d'autres moyens (pare-feu, ...)
4  1 
Avatar de o.may
Futur Membre du Club https://www.developpez.com
Le 27/01/2015 à 11:37
Ceux qui estiment que publier une faille après un délai permet aux utilisateurs de se protéger, j'aimerai bien que vous m’expliquiez comment tous les utilisateurs "moyens" sont censés se protéger, tous seuls ? Ils sont déjà harcelés de faux messages jouant sur le peur du virus et du piratage, comment vont-ils faire le tri ? S'ils le font, comment savoir quoi faire ? D'autant plus avec des logiciels propriétaires fermés ??
Si la faille est corrigée avant les 90 jours, elle est intégrée dans un patch. Les utilisateurs moyens laissent en général la configuration par défaut. Les éléments critiques (OS, navigateur, Flash, Java...) ont par défaut des mises à jour automatiques. Les éditeurs ont aussi une grande responsabilité en devant mettre en place des mises à jour de sécurité automatiques. Et les gens qui les désactivent savent ce qu'ils font.
3  0 
Avatar de Shuty
Membre éprouvé https://www.developpez.com
Le 26/01/2015 à 13:33
Je pense qu'il est nécessaire de publier les failles au bout d'un délai fixe, car c'est le seul moyen de forcer un peu la main aux éditeurs récalcitrants pour qu'il sortent des correctifs.
Je pense que tout est dit. Passé un délais, la publication doit être faite car il faut tout de même que les utilisateurs puissent s'en protéger... Et sans être informé d'une quelconque faille, on ne la devine pas...
3  1