Discussion :

[Hinault Romaric]

Les failles de sécurité doivent-elles être rendues publiques ?
Procéder ainsi est-il bénéfique pour les utilisateurs ?

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 ?

[gangsoleil]

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.

[Shuty]

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...

[psychadelic]

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 ?

[ZenZiTone]

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...

La meilleur protection pour l'utilisateur ne serait-elle pas un patch correctif? Car je ne pense pas que tous les utilisateurs s'intéressent aux publication des failles de sécurité système...

Je suis aussi de l'avis de donner un délai à l'éditeur, mais dans le but de faire pression sur lui pour qu'il apporte une correction au plus vite. L'idéal étant qu'un correctif soit proposé systématiquement avant la publication de la faille.

[psychadelic]

La meilleur protection pour l'utilisateur ne serait-elle pas un patch correctif? Car je ne pense pas que tous les utilisateurs s'intéressent aux publication des failles de sécurité système...

Comment veux tu que l'éditeur puisse produire un correctif s'il ignore qu'il y a une faille ?
Comment veux tu que celui qui découvre la faille puisse produire un patch sur du code qu'il ne possède pas ?
ton argument n'a pas de sens.

Je suis aussi de l'avis de donner un délai à l'éditeur, mais dans le but de faire pression sur lui pour qu'il apporte une correction au plus vite. L'idéal étant qu'un correctif soit proposé systématiquement avant la publication de la faille.

C'est justement ce quil se passe actuellement : l'éditeur est prévenu de sa faille, et s'il ne réagit pas, la faille est rendue publique au bout de 90 jours...

t'a l'air de découvrir ses questions, c'est bien de donner ton avis, mais stp, renseigne toi un minimum avant...

[M_Makia]

Pour moi cette question n'est pas si facile.

Sur le fond je suis d'accord de contraindre ou de faire pression sur des éditeurs pour qu'ils corrigent leurs failles le plus rapidement possible.
Cependant en rendant publique une faille non corrigée il ne faut pas oublié que les principales victimes sont les utilisateurs.

Une des questions que je me pose c'est :
=> Est ce que quelqu'un qui publie une faille non corrigé impactant des 10 de millions d'utilisateurs (voir des 100 de M) prend une partie de la responsabilité sur les potentiels attaques ou virus que cette faille engendre lorsqu'elle est divulguée ?

[ZenZiTone]

Comment veux tu que l'éditeur puisse produire un correctif s'il ignore qu'il y a une faille ?
Comment veux tu que celui qui découvre la faille puisse produire un patch sur du code qu'il ne possède pas ?
ton argument n'a pas de sens.

Elément de réponse :

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.

Mais tu avais déjà la réponse :

C'est justement ce quil se passe actuellement : l'éditeur est prévenu de sa faille, et s'il ne réagit pas, la faille est rendue publique au bout de 90 jours...

Et à mon avis c'est une bonne manière de procéder.

[Haseo86]

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

Bien sur une faille non publié ne garantit pas qu'elle sera exploitée, mais une faille publiée marquée en gros "je ne suis pas corrigée", c'est une invitation envoyée à tous les hackers malhonnêtes qui ne la connaissaient pas encore de se faire plaisir. C'est juste irresponsable et démagogique (surtout de la part de Google, mais c'est un autre débat).

[disedorgue]

Bonjour,

Pour moi, la procédure de google est dans les clous, si en 3 mois, ils n'ont pas réussi à corriger la faille, c'est qu'il y a vraiment un problème dans l'application.
Après, il doit bien y avoir un moyen de dire qu'il y a des failles dans une application sans rendre publique les dites failles mais de les communiquer à l'éditeur.

[psychadelic]

Elément de réponse :
Mais tu avais déjà la réponse :
Et à mon avis c'est une bonne manière de procéder.

Je ne faisais que répondre à ta question: La meilleur protection pour l'utilisateur ne serait-elle pas un patch correctif?
Stp relis toi un peu !

[psychadelic]

Une des questions que je me pose c'est :
=> Est ce que quelqu'un qui publie une faille non corrigé impactant des 10 de millions d'utilisateurs (voir des 100 de M) prend une partie de la responsabilité sur les potentiels attaques ou virus que cette faille engendre lorsqu'elle est divulguée ?

Le problème de ta formulation, c’est qu’elle dédouane de toute responsabilité l’éditeur du logiciel.

On peut la poser différemment : Est-il normal que l’éditeur d’un logiciel vendu à des millions d’exemplaires fasse passer la sécurité en second plan ???

Si on veut prendre exemple sur la nature, on a la biodiversité : de multiples formes pour de mêmes finalités, en cas virus ou autre maladie, la contamination ne peut pas s’étendre démesurément..

[gangsoleil]

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, ...)

[psychadelic]

Bien sur une faille non publié ne garantit pas qu'elle sera exploitée, mais une faille publiée marquée en gros "je ne suis pas corrigée", c'est une invitation envoyée à tous les hackers malhonnêtes qui ne la connaissaient pas encore de se faire plaisir. C'est juste irresponsable et démagogique (surtout de la part de Google, mais c'est un autre débat).

C’est une très vieille méthode ton truc, elle date même de l’antiquité !
(Si le message est mauvais, on tue le messager !)

Mais au cas où tu ne saurais pas elle ne donne aucun résultat.

En informatique comme ailleurs, on n’est pas dans le monde des Bisounours !

Tous les logiciels que vous utilisez sont susceptibles d’avoir des failles de sécurité.
Et quasiment aucune société ne s’intéresse à traiter ce sujet.

Rien n’empêche Microsoft, ou Apple de monter des équipes pour chercher des failles sur Androïd ou Chrome OS.

[ZenZiTone]

Je ne faisais que répondre à ta question: La meilleur protection pour l'utilisateur ne serait-elle pas un patch correctif?
Stp relis toi un peu !

Dans ce cas on s'est mal compris. Ma question n'en était pas réellement une, mais plutôt une remarque sur ce qu'avait dit Shutty...

[M_Makia]

Le problème de ta formulation, c’est qu’elle dédouane de toute responsabilité l’éditeur du logiciel.

On peut la poser différemment : Est-il normal que l’éditeur d’un logiciel vendu à des millions d’exemplaires fasse passer la sécurité en second plan ???

Si on veut prendre exemple sur la nature, on a la biodiversité : de multiples formes pour de mêmes finalités, en cas virus ou autre maladie, la contamination ne peut pas s’étendre démesurément..

Je me suis certainement mal exprimé.
Tout le monde s'accorde a dire que c'est anormal qu'un éditeur ne corrige pas suffisamment rapidement ses failles de sécurités.
Ma question met en effet l’éditeur de coté (car on connait ses responsabilités) pour mettre en avant la responsabilité de celui qui divulgue la failles et les conséquences potentiellement énorme que cela peut avoir sur les utilisateurs et bien sur les entreprises qui compte énormément sur leur système d'information.

[psychadelic]

Gangsoleil à répondu à cette aspect de ta question.

Dans un premier temps, seul l’éditeur du logiciel à connaissance de la faille.
S’il ne la corrige pas, passé un délai celle-ci est publiée, et les entreprises comme les particuliers, qui utilisent le logiciel impliqué peuvent agir en conséquence : sur leur parfeu, désactiver une fonctionnalité, etc… le temps qu’un correctif soit publié.

C’est arrivé ces derniers jours avec Flash, et j’ai moi-même, comme beaucoup d’autres internautes désactivé Flash de mes systèmes, et je ne l’activais que pour des « sites de confiance ».
Le correctif d’Adobe est arrivé ce matin, finalement cela m’a privé de YouTube que pendant 2 jours.

La seule chose que j’espère, c’est cette faille n’était pas déjà connue et exploitée avant que Google ne la trouve.



Pour la partie sécurité, plus on aura des logiciels incompatibles entre eux pour une même fonctionnalité.
Moins on aura de solutions de repli vers d’autres logiciel compatibles, ne serait-ce que le temps que celui qui est « infectable » soit fiabilisé.

Et cela fonctionne même dans le cas ou une faille non détectée commence à faire ses ravages.

[Laurent 1973]

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.

[anto38fr]

Bonjour,

je suis le seul a me demander en quoi Google se permet une chose pareil? Sur le principe je dit pas, il y a de l'idée. Mais je n'arrive pas a comprendre en quoi Google a le droit de faire sa. Divulgué une faille non corriger devrais être (si divulgué elle doit être) de la responsabilité d'une société ayant reçu l'autorité nécessaire.

Éclairez ma lanterne

[psychadelic]

Bonjour,

je suis le seul a me demander en quoi Google se permet une chose pareil? Sur le principe je dit pas, il y a de l'idée. Mais je n'arrive pas a comprendre en quoi Google a le droit de faire sa. Divulgué une faille non corriger devrais être (si divulgué elle doit être) de la responsabilité d'une société ayant reçu l'autorité nécessaire.

Éclairez ma lanterne

Simple, Google doit veiller sur sa propre sécurité.

Il ont des « tonnes » de machines : serveurs, PC, Smartphones, de toutes marques et utilisées par presque 50.000 employés, et sur lesquels y il a pas mal d’informations confidentielles, et vitales.

Alors, pour eux, la sécurité est une préoccupation centrale, et les "chapeaux noirs" ne leur font pas de cadeau à eux non plus.

Ils ont plusieurs équipes qui ne travaillent que sur ces questions.

Et cette recherche en sécurité est tout azimuts, y compris sur leurs logiciels (et en priorité) comme Androïd, Chrome, Chrome Os, etc…