Coup de griffe : Microsoft a ouvertement critiqué Google pour avoir publié des informations sur une faille deux jours avant que le correctif ne soit disponible. Alors que Redmond rappelle qu’une concertation est nécessaire pour gérer les brèches, Google se défend de son côté en rappelant qu’elle en publie toujours les détails trois mois après leur découverte.
Les détails d'une faille révélés deux jours avant la publication du correctif
Microsoft et Google ont des politiques parfois incompatibles au sujet des failles. La firme de Mountain View dispose d’une équipe efficace de chercheurs en sécurité, souvent remerciés par la concurrence, y compris par Microsoft. Mais cette dernière est agacée : dans un billet publié hier, l’un des responsables de la sécurité, Chris Betz, critique Google pour avoir publié aux yeux de tous les détails d’une faille qui sera corrigée demain.
Pourquoi un tel empressement ? Parce que Google dispose d’une politique relativement stricte en la matière, le Project Zero. L’énoncé en est simple : les détails d’une faille seront publiés 90 jours après que l’éditeur concerné a été averti de la situation. Dans le cas présent, Microsoft a été averti le 11 octobre dernier, situant la date limite au 11 janvier, hier donc. Les détails de la faille sont alors devenus publics, provoquant la colère de Microsoft. Mais Google s’était déjà défendu lors d’un cas similaire en décembre dernier après trois mois de discussion.
Aucun avantage à une telle publication pour Microsoft
Chris Betz a donc exposé la vision de l’éditeur sur ce type de pratique, critiquant un calendrier aveugle : la politique des 90 jours est ce qu’elle est, mais pourquoi fallait-il absolument publier ces détails deux jours avant le correctif ? Pour Betz, il n’y a qu’une seule explication possible, Google ayant voulu jouer la carte « On vous a eus ! » plutôt que de jouer celle de la responsabilité.
La vision de Microsoft sur le sujet est clairement antagoniste. Il ne peut ainsi y avoir de publication des détails sans aucun contexte, ce qui est justement le résultat du Project Zero. Selon Chris Betz, de telles informations ne font qu’augmenter le danger et Google a tort de croire que les travaux s’en retrouveront non seulement accélérés, mais également que les utilisateurs seront mieux protégés. Comment ? Parce qu’ils seront avertis et prendront les mesures qui s’imposent.
C’est précisément là que Betz insiste : les utilisateurs ne sont en aucun cas mieux protégés, au contraire. Et la preuve en est évidente car quantifiable. Ainsi, selon des analyses internes, il n’y a pratiquement pas d’exploitation des failles révélées en privé, à l’inverse de celles qui deviennent publiques. Il est vrai d’ailleurs que l’immense majorité des utilisateurs n’a que faire de ce type d’informations et n’a que peu conscience des problématiques de sécurité. En outre, comme l’indique Betz, les détails de ces failles peuvent profiter aux pirates, tout en ne comportant aucune instruction pour les utilisateurs. Sans guide ou recommandations, comment se préparer à l’éventualité d’une attaque ?
Simple question de philosophie ou petit coup de griffe ?
Microsoft est en fait une fervente partisane de la méthode « Coordinated Vulnerability Disclosure ». Là encore, le principe est simple : les différents acteurs impliqués dans la chaine de sécurité communiquent de manière privée, et aucune information publique ne peut être donnée tant que le correctif n’est pas disponible. Le temps n’est donc pas un critère. Il y a cependant une exception : la découverte d’une exploitation de la faille pendant que l’éditeur travaille sur le correctif, auquel cas les détails deviennent publics, accompagnés de mesures de réduction des risques (« mitigation »).
Les deux firmes ont donc une vision opposée de la responsabilité envers les utilisateurs, mais la solution ne serait-elle pas quelque part à mi-chemin entre ces deux visions ? Par exemple, rendre les communications privées pour éviter que les pirates n’en profitent, tout en définissant un délai plus long au-delà duquel il serait évident que l’éditeur doit être « motivé ».
Commentaires (78)
#1
Plutôt du côté de Microsoft sur ce coup.
Il est un peu utopique de penser qu’un utilisateur va aller lire un billet publié par Google concernant les failles découvertes sur Windows.
Au delà même de le lire, je doute que, même si le billet était largement relayé, plus de 5% des utilisateurs Windows prennent la peine de désactiver temporairement tel ou tel service vulnérable le temps qu’un correctif soit dispo.
Après les règles sont les règles, on connait la politique de Google et de leur publications à m+3, mais à deux jours près…
#2
#3
Je suis plutôt d’accord avec MS pour le coup. Surtout que les utilisateurs lambda des fois ne font pas les MAJ des failles connues (parce qu’ils n’y comprennent rien et parce que ça les gonflent).
C’est pas afficher le contenu de la faille en faisant “ha vous aviez qu’à vous bouger les fesses” qui va arranger la situation surtout à deux jours près… MS n’aurait même pas pris la peine de corriger la faille, je dis pas. Mais là, la correction doit être poussée sous peu, le comportement de Google est débile.
#4
La première règle en matière de sécurité est de ne pas faire d’exception aux procédures.
Cependant la procédure de google est peut-être à revoir.
#5
Je ne sais pas si trois mois c’est suffisant pour corriger tous les types de faille, mais je trouve ça bien de respecter un calendrier de la sorte. Ça met un coup de pression sur les éditeurs qui traînent parfois à combler les failles de leurs systèmes alors qu’ils ont été signaler depuis longtemps.
C’est plus le temps laissé par google qu’il faut juger en fait, et là j’ai du mal à me faire un idée.
S’ils acceptaient une demande pour repousser la publication alors tout le monde pourrait le faire, autant repousser le délais alors.
#6
#7
Ce qui est anormal et inadmissible, c’est de diffuser une faille de manière publique sans proposée de solution!!!!
#8
#9
#10
Ils n’ont pas les ressources nécessaires pour corrigés les failles rapportées depuis 90 jours chez Microsoft
" />?
" />
Enfin surtout ce n’est que le mardi que le correctif est publié chez Microsoft…
#11
#12
Mouais je suis d’accord avec M$ sur ce coup-là. Ok ils ont un processus automatique qui publie au bout de 90 jours, mais dans ce genre de cas, personne ne viendra râler si le délai passe à 92 jours. Comme l’article le dit, le grand public n’a que faire de ce genre d’info (dont il ne connaît de toutes façons pas l’existence), en revanche les gens malintentionnés sont à l’affût.
Sans compter qu’entre la mise à disposition d’un correctif de sécurité et son application à chiffre au pif 60% du parc mondial concerné, il doit déjà y avoir pas mal de temps qui s’écoule…
#13
question novice : Est-ce que Google fait la même chose avec des faille qu’ils découvrent eux même sur leurs propres produits ? A m+3 corrigé ou pas hop ils balancent ?
#14
Ben perso 3 mois je trouve que c’est valable si tu pousses les MAJ de manière obligatoire chez les clients, sinon c’est le temps qu’il faut laisser entre publication du correctif et publication de la vulnérabilité histoire que tout le monde ait passé ses mises à jour.
" />
Microsoft laissant le client libre de ptacher ou pas je pense que c’est juste de la mauvaise foi de la part de google et un outil anti concurentiel.
Google comme apple et tous les autres bricolos n’assurent quasi pas de rétrocompatibilité. Donc ils s’en foutent. Microsoft qui a plein de clients chez qui juste valider un patch pour un progiciel peut prendre plusieurs mois ne peut pas se le permettre.
C’est un signe de manque de professionnalisme de la part de Google et une pratique commerciale agressive et abusive. On ne peut qu’espérer que Microsoft porte plainte contre eux pour cela et qu’ils cessent immédiatement de se comporter comme des trous du
#15
C’est pas faux, c’est vrai que dans les grosses boites tout est plus lent
" />
#16
#17
Google n’a pas les mêmes contraintes de rétrocompatibilité surtout, les gens qui sont sur des applis SAAS n’ont effectivement pas de mises à jour à faire, c’est l’éditeur qui les pousse donc ça va plus vite. Dans le modèle microsoft, où les sociétés et particuliers sont souverains sur leur SI et leurs données il faut laisser au client final le temps de valider les correctifs proposés.
Généralement c’est sans douleur mais si ça implique le blocage de certaines fonctions, l’ajout de certificats, l’ouverture de droits supplémentaires etc. il faut que les clients finaux puissent tester et amender leur SI. 90 jours c’est beaucoup trop peu pour que tout cela ait lieu dans des SI complexes.
#18
Ben attendu que les constructeurs ne poussent plus les mises à jour généralement un an à un an et demi après la vente des terminaux c’est quasi certain que non.
#19
#20
#21
#22
Sachant que :
Je trouve que la politique de Google est claire pour le coup, et qu’elle est justifiée : ils ont trouvé une faille, ils en avertissent l’éditeur, et 90 jours après ils la rendent publique.
Microsoft a été pris de court à cause de sa politique «on sort les patches le second mardi du mois», soit demain. S’ils veulent éviter une telle situation, soit ils sortent le patch en dehors de ce cycle, soit ils changent de politique de patch…
Je comprends parfaitement que les entreprises aient besoin d’un cycle régulier pour le déploiement des patches : contrôler les redémarrage, rester en production, etc. Ce que je ne comprends pas, c’est que le même cycle est imposé aux particuliers qui, eux, peuvent redémarrer tous les jours.
Si j’ai bien compris, avec Windows 10 Microsoft a l’intention de dissocier les entreprises (cycle régulier de patch) et les particuliers (distribution de patches en continu). Ça semblerait déjà plus logique.
Comment proposer une solution quand le code source est fermé ?
#23
Tout à fait d’accord à tous les niveaux, mais j’irai même plus loin :
#24
#25
#26
#27
#28
#29
Perso je suis plutôt du coté de Google. La politique des 90 jours est une sorte d’épée de Damoclès, qui garantit que les éditeurs vont se bouger le c et mobiliser tout les moyens nécessaires pour corriger une faille au plus vite. Ainsi, on est sur qu’ils ne seront pas tentés de grappiller quelques \( (ou millions de \)) en limitant les moyens consacrés à la correction des failles.
PS: comment explique t’on que les logiciels libre voient leurs failles en général corrigées dans les heures qui suivent, et que M$ ait besoin de plus de 90 jours pour faire de même?
#30
#31
#32
90 jours pour une faille connu sur un logiciel critique que l’on paye cher, c’est minable.
je vois pas comment on peut être du coté de MS. Sur Android, les applications sont mise à jours quasiment en temps réel, et je parle pas de l’OpenSource : On a JAMAIS eu à attendre autant sur TOUS les logiciels Open source connu, malgré leurs moyens bien inférieur.
#33
#34
tu connais 1 autre éditeur VIVANT mettant plus de 90 jours à corriger une faille critique?
#35
#36
#37
Microsoft s’attend à des cadeaux de la part de son ennemi ? Franchement drôle… Je vais sûrement dire une grosse bêtise, mais le “patch tuesday”, c’est pas gravé dans le marbre, si ? Ca coîte quoi si ça devient un “patch saturday” pour une fois ? Connaissant les règles, si MS avait mis en ligne son patch 3 jours plus tôt, l’affaire était réglée, non ?
Enfin, moi, je dis ça depuis mon linux, où les patches sont publiés dès leur validation, et plus ils sont importants plus ils sont vite publiés, donc j’ai pris de mauvaises habitudes… ;o)
#38
#39
Microsoft connait le coup des 90 jours… plutôt que de râler maintenant, il aurait plutôt fallu contacter Google avant la publication de l’annonce.
#40
C’est ce qui a été fait…
Microsoft avait demandé de décaler de 2 jours la publication le temps que le patch tuesday arrive à son rythme habituel (car le correctif de la faille est bien prévu pour mardi). Google a dit non.
Du coup si Microsoft voulait éviter ce problème, selon leur politique de mise à jour, ils auraient eu 28 jours de moins pour travailler sur la maj.
#41
Tu veux dire, comme ce qu’ils expliquent texto dans leur billet?
CVD philosophy and action is playing out today as one company - Google - has released information about a vulnerability in a Microsoft product, two days before our planned fix on our well known and coordinated Patch Tuesday cadence, despite our request that they avoid doing so. Specifically, we asked Google to work with us to protect customers by withholding details until Tuesday, January 13, when we will be releasing a fix. Although following through keeps to Google’s announced timeline for disclosure, the decision feels less like principles and more like a “gotcha”, with customers the ones who may suffer as a result. What’s right for Google is not always right for customers. We urge Google to make protection of customers our collective primary goal.
#42
#43
Ou ai-je parlé de Google pour les contributeurs ? Ou ai-je parlé de malwares ? La plupart des fails critiques permettant d’infecter plus profondément les OS ne proviennent quasi plus de l’OS lui même…
Pour ce qui est de patcher gratuitement un OS, simple, c’est un vecteur pour attaquer/infecteur d’autres PC, donc quelque chose qu’il faut stopper tout simplement.
Et je n’ai pas non plus parlé de savoir si MS avait ou non le patch sous le coude.
#44
#45
#46
#47
#48
Je n’ai pas dit que Google aurait du proposer le patch, je sais pas ou t’as lu ça, mais ça ne vient pas de moi. Ne fait pas de cross-post. Je répond a ta propre question “comment proposer un patch quand le code est fermé” par une autre question, comment font ceux qui patch sans avoir acces au code source, ensuite t’es parti sur le début de mon post expliquant que non, c’est pas plus simple de coller une rustine sur de l’AOSP que sur Windows.
Si tu veux mélanger les propos soit, mais pas les miens. :)
#49
#50
Personne ne se demande comment ça se fait que c’est encore le seul Microsoft qui est à se plaindre…
Message à Microsoft : Engagez du personnel et cessez de vous plaindre, car vous semblez ridicule à toujours être le seul à vous plaindre quand le reste de l’industrie travaille à protéger ses outils..
Pourtant ils ont des marges de plus 42% selon leurs derniers bilans, bien au delà de Apple qui pointe autour de 37%, c’est pas l’argent qui manque, sauf quand on s’en fout un peu de ses clients..
#51
Peut être parce que MS se s’amuse pas à divulguer publiquement les failles de produits de ses concurrents en leur disant “je t’avais dit : 90 jours”
Donc peut être que Google pourrait arrêter de nous les briser et réallouer son budget “je divulge les failles Windows parce que c’est marrant” vers son projet “ je me démerde pour que Android 5.0 bouffe pas de la mémoire pour rien”, voir même le projet “un jour Chrome OS saura lire un fichier mkv avec du son”.
Et puis, peut être que si c’est pas l’argent qui manque c’est que, justement, c’est pas un problème de moyen, mais un problème de “on doit sortir un patch pour xxxxx versions sur yyyyy configurations différentes, de manière transparente, en testant tout”, le tout sans perturber le calendrier des adminstrateurs IT de leur clients qui s’attendent (et sont préparés) à un patch le deuxième mardi du mois, et pas quand ca chante à Google.
#52
???
Donc ils ont pas les moyens pour recruter du personnel compétent pour la sécurité de leurs clients ?? (la boite IT la plus rentable)
Donc des pirates qui ont découvert cette faille avant Google (oui Google n’a pas le monopole de découverte de failles) peuvent continuer à l’exploiter ??
Bref du Microsoft pur jus, toujours les mêmes depuis 20 ans.
#53
#54
#55
Dans le monde informatique un tant soit peu complexe, on ne patche pas des logiciels à plusieurs millions de ligne de code à la va vite sans vérifier les potentiels régressions.
Une faille méconnue est peut être moins dangereuse qu’une régression majeure sur un des milliers/millions de clients.
Vu la quantité d’architecture supporté et la taille de Windows, un cycle complet de qualification doit bien leur prendre quelques semaines.
#56
les autres le font, c’est culotté de reprocher à d’autre de découvrir des failles, de les divulguer après 90 jours. Personne d’autre ne le fait.
Windows n’est plus un sac de nouille. Faut pas exagérer la complexité dans leur contexte. Ils ne sont pas nul à ce point. On parle d’une faille de W8.1, pas MS-DOS.
#57
#58
Et pendant que Google est occupé à faire la guéguerre à MS, l’on apprend qu’ils ne jugent pas utile de patcher les failles d’Android : Faites ce que je dis, ne faites pas ce que je fais!
#59
#60
Et d’ignorer la grammaire, aussi.
#61
#62
Les autres?
Tu en connais beaucoup des boites qui maintiennent 8 versions d’os, et doivent tenir compte de quelques milliers de configurations différentes, avec l’obligation d’avoir des process pour valider au maximum la non régression tout en le mettant à dispo simultanément pour plusieurs centaines de millions de machines ?
#63
#64
#65
effroyable, effroyable … vite dis ça sans jamais avoir compté !
moi@salon:/usr/src/linux-source-3.2/drivers$ find . -type f | xargs wc -l
1913550 total
moins de deux millions \o/, oui j’ai une debian, là ce ne sont que les drivers matériel, je t’autorise a les enlever du décompte total.
edit : je viens de tomber dans le troll !
#66
#67
Sous GNU/Linux, on n’attend pas une date précise pour publier le correctif - dès que c’est près, ça sort… C’est là où la sécurité par l’obscurantisme échoue chez les concurrents : ces gens manquent tout simplement de réactivité.
#68
#69
J’ai un nexus 5 et je viens d’acheter un chromebook…
Je parle en connaissance de cause. Et en tant qu’utilisateur Google je préfèrerais que Google pas moins de temps à s’occuper des fesses de MS et plus des siennes.
#70
“dans le domaine des logiciels libres, une faille découverte est une
faille rendue publique (cf les exemples de HeartBleed, ShellShock, pour
ne parler que des plus récentes) ;”
Dans les cas cités (HeartBleed & ShellShock), les découvreurs de la faille ont pris soin d alerter les personnes responsables des paquets incriminés et autre dev (par ex les dev Debian) avant de la rendre public. Ce fut l histoire de 2-3j seulement.
Mais on peut difficilement comparer/discuter de la durée nécessaire à un patch sans connaitre son contexte. Je ne suis pas sûr qu une durée fixe soit une si bonne idée…
#71
Ne pas avoir de Ctrl+F c’est la plaie. Et chercher dans un bouquin de 1500 pages, c’est chiant.
J’ai pas retrouvé tous les passages exacts mais j’ai celui-là :
A.Tanenbaum - Modern Operating Systems. “When essentials libraries are included [ndlr : grosso modo, l’API Win32 et le .Net minimal], Windows is well over 70 million lines of code” (ça exclut bien sûr les choses comme Windows Media, Internet Explorer, etc … qui feraient exploser littéralement le nombre de lignes). Les chiffres sont basés sur Windows 7, il n’y a pas d’info pour 8, mais a priori avec les nouvelles API + résidu historique, ça a dû gonfler pas mal.
Donc grosso modo, sur la code base Windows 7, c’était de l’ordre de 70 millions de lignes. Par contre je n’arrive pas à retrouver le passage vraiment intéressant qui concernait le kernel.
#72
Autant google n’a pas été sympa de ne pas repousser de deux jours la release de la faille, autant pour moi les 90j c’est une longue durée pour garder ce genre de chose secrète..
c’est à dire que pendant 90j, si un pirate exploite cette même faille, microsoft se retournera contre google en l’accusant d’avoir laissé leaker la faille au plus offrant? combien de personnes sont au courant de ces failles ? est ce qu’on peut leurs faire confiance?
Autant je veux bien que 90j c’est court dans un cycle de développement d’une code base comme celle de Microsoft, mais c’est une longue durée pour garder un secret qui a potentiellement un impact financier énorme pour Microsoft ..
#73
Remarque que j’avais cru comprendre en te lisant que tu devais avoir une machine sous Andro LL et que tu avais au moins déjà essayé un chromebook.
" />
" />
Je trouve juste que dire à Google “mêlez-vous de vos fesses” n’est pas vraiment le sujet. Mais bon… je taquinais juste en passant…
#74
On a souvent lu que la NSA faisait tout son possible pour abaisser la fiabilité des algorithmes de chiffrement, des générateurs de nombres aléatoires… voir, tout simplement, de la sécurité dans son ensemble.
Les États-Unis ont beaucoup misé sur leurs capacités offensives, au détriment de leur propre sécurité (et c’est à ce moment là que vous vous demandez quel peut bien être le rapport avec la choucroute).
Dans le même temps, la Chine, la Russie, et sûrement tout un tas d’autres pays (sans parler des groupes mafieux), se sont mis à engager des légions de développeurs, de hackers, d’experts en sécurité, pour lire chaque nouveau commit du kernel Linux et autres logiciels libres, pour voir si une faille exploitable ne se serait pas glissée dans la foulée. Et bien évidemment, même chose du côté de Windows, ou de tout autre logiciel populaire.
Croire que Microsoft et les USA peuvent encore prendre leur temps de corriger leurs failles, qu’il n’y a pas à s’inquiéter, qu’ils sont les plus forts et qu’il n’y a rien à craindre, me fait doucement rigoler.
Ça se trouve, la faille en question est déjà exploitée depuis belle lurette par le malware d’une force étrangère qui ciblerai précisément les USA. De l’un de ceux que l’on découvre de temps en temps et dont on apprend qu’ils sont en circulation depuis cinq ou six ans, et dont on apprend seulement maintenant l’existence.
Le monde a changé. De mettre trois mois à corriger une faille puis se décider à sortir le correctif, pour ensuite attendre encore quelques mois que les entreprises et autres administrations se décident enfin à mettre à jour, je trouve ça complètement aberrant et irresponsable.
#75
En fait les logiciels libres patchés rapidement ainsi n’assurent aucun test de rétrocompatibilité en amont. Donc c’est rapide mais c’est potentiellement sale d’un point de vue client final qui ne peut pas forcément couper sa prod le temps d’un redéveloppement de composant. Ca n’est pas pratique du tout pour une DSI de bosser avec ce type de contrainte.
Ca déplace sur le client final la charge de se démerder en résumé…
Outre que ça implique une grande réactivité du client final, ça implique également un net surcout qui n’est absolument pas justifiable pour une faille non exploitée.
#76
Adobe?
#77