Windows 10 : que trouvait-on vraiment dans la fuite de données de ce week-end ?
Beaucoup d'azote, un peu d'oxygène
Le 26 juin 2017 à 10h00
6 min
Logiciel
Logiciel
Depuis ce week-end, les articles font rage : 32 To d’informations diverses sur Windows 10 auraient fuité, dont une partie du code source de Windows 10. Dans la pratique, la fuite est nettement moins importante, mais pose quand même de sérieuses questions de sécurité.
Vendredi soir, The Register publiait un article explosif : 32 To de données diverses au sujet de Windows 10 ont été trouvés sur le site BetaArchive, spécialisé dans les dépôts de préversions et de logiciels abandonnés.
Nos confrères évoquaient alors un mélange de versions internes ainsi que le code source du cœur du système d’exploitation. Ils estimaient également que la fuite devait avoir eu lieu en mars dernier, les données ayant a priori été « exfiltrées » directement depuis les locaux de l’entreprise. Bien qu’une partie des données puisse être sensible, il semble cependant qu’on soit loin d’une fuite réellement dramatique.
32 To de données ? Oui, mais…
D’abord, que contiennent ces fameux 32 To, dont la forme compressée descend à 8 To ? En bonne partie, tout un lot de préversions de Windows 10 qui ont été compilées en interne, mais non mises à disposition du public.
Rien de bien incroyable dans l’absolu : Microsoft compile très régulièrement de nouvelles moutures, notamment pour le programme Insider qui permet de tester les bêtas du système. C’est d’ailleurs le sens des numéros de builds affichés en bas à droite. Par exemple, le numéro est passé récemment de 16215 à 16226 dans le canal rapide. L’explication est simple : il y a eu 11 compilations du système entre les deux.
La plupart de ces préversions sont de la branche Redstone 2, qui a abouti pour rappel à la Creators Update distribuée en début avril (la branche de développement est actuellement la Redstone 3). Parmi les builds, on en trouve des classiques, mais également certaines compilées pour ARM64, tandis que d’autres contiendraient des symboles privés de débogage, qui peuvent être riches d’informations.
L’archive contenait également deux autres composants. D’abord, plusieurs moutures du Mobile Adaptation Kit, outil interne servant à préparer Windows 10 pour une installation sur les appareils mobiles (les smartphones en l’occurrence). Ensuite, et surtout, un kit appelé Shared Source, et c’est ici que la situation peut se compliquer.
Pas le cœur du système, mais des composants importants
BetaArchive a réagi de son côté, essentiellement pour calmer le jeu et expliquer ce qui se trouvait réellement dans cette archive. Confirmant la présence de nombreuses builds n’ayant pas été distribuées publiquement, le site précise leur provenance : un réseau de membres du forum, participant aux programmes Insider ou Connect. En clair, il s’agirait de sources « légitimes », en aucun cas d’une fuite provenant de Microsoft.
Surtout, l’archive contenait un dossier de 1,2 Go, contenant douze versions différentes du Shared Source Kit. Ce dernier contient le code source de certaines piles de Windows 10, notamment pour l’USB, le stockage, le Wi-Fi ou encore le Plug-and-Play. En d’autres termes, ce que les partenaires matériels peuvent être autorisés à voir pour le développement des pilotes.
Ce code source est accompagné d’une licence spécifique appelée elle aussi Shared Source. Elle permet essentiellement de le consulter, même si dans certains cas il est possible de redistribuer une version modifiée. Ce n’est toutefois pas une licence commerciale, et elle n’est pas reconnue comme open source.
Le problème des sources visibles
Rien dans le Shared Source Kit ne concerne à proprement parler le cœur du système, contrairement à ce qu’indiquait initialement The Register. Cependant, les piles liées aux pilotes restent des composants importants, et la visibilité du code source pourrait entrainer des soucis de sécurité.
BetaArchive a supprimé tout le dossier, et ne compte pas le remettre en ligne dans l’immédiat, une analyse étant en cours pour déterminer si le risque est écarté. Cependant, puisque les données étaient accessibles via FTP à quiconque avait les bons identifiants, il y a fort à parier que le code source circule désormais entre de nombreuses mains.
Si ce code devait révéler des failles de sécurité, tout dépendrait alors de la personne qui les trouverait. Il y a surtout deux possibilités : soit la vulnérabilité est signalée directement à Microsoft, soit elle est mise de côté. Quand on sait quel trafic règne dans ce domaine, on imagine aisément que certains se frottent déjà les mains.
Des failles dans les piles pourraient en effet mener des pirates à développer des pilotes vérolés. Selon le type, les fameux « drivers » ont plus ou moins de privilèges, bien que les différentes versions de Windows les aient réduits avec le temps, en repoussant la plupart en espace utilisateur. Cependant, une brèche pourrait justement permettre des élévations de privilèges et globalement une percée à travers les défenses.
Et maintenant ?
Dans une réaction publiée samedi, BetaArchive indique que tout ce qui touchait au Shared Source Kit a bien été supprimé, mais pas les builds. Microsoft a confirmé également à The Register que le dossier du SSK contenait « une partie » du kit. Conséquence, on ne sait pas exactement quelles sont les piles qui se trouvaient dans l’archive, du moins pas encore. Nous avons d’ailleurs demandé à Microsoft de plus amples informations et attendons actuellement une réponse.
Pour l’instant, il est difficile de calculer les retombées de cette « fuite ». Il ne s’agit pas, comme on a pu le voir sur divers sites, du code source de Windows, mais de celui de quelques composants auxquels de nombreux partenaires avaient déjà accès via la Shared Source Initative. Des informations techniquement suffisantes pour entrainer des soucis de sécurité, même si tout repose finalement sur le code lui-même.
Windows 10 : que trouvait-on vraiment dans la fuite de données de ce week-end ?
-
32 To de données ? Oui, mais…
-
Pas le cœur du système, mais des composants importants
-
Le problème des sources visibles
-
Et maintenant ?
Commentaires (47)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 26/06/2017 à 10h19
La visibilité du code source pourrait entrainer des soucis de sécurité….
C’est une blague ??? C’est clairement indigne d’un “journaliste” qui se dit spécialiste en OS d’écrire ça de nos jours…
Le 26/06/2017 à 10h20
Je suis hyper déçu.
En fin de compte, je ne trouve même pas moyen de me moquer.
Le 26/06/2017 à 10h22
Le 26/06/2017 à 10h22
On verra mais il semble que ça soit pas si grave que ça.
Et sinon, quand MS fera une mise à jour de W10 Insider propre !!!
3 plantages sur SetupPlateform.exe et là, j’ai fais une réparation et je tente une dernière fois !!!
Le 26/06/2017 à 10h22
Et on a une idée de l’origine de la fuite ?
Le 26/06/2017 à 10h24
Le 26/06/2017 à 10h25
Le 26/06/2017 à 10h28
Ben c’est le faite que comme dab le code n’est pas visible la sécurité n’est pas forcement au point la dessus… du coup le pb c’est que du code sensé rester privée soit devenue visible… Je vois pas ou il y a problème de journalisme.
Le 26/06/2017 à 10h30
+42. Mais je ne suis même pas surpris concernant ce rédacteur.
Le 26/06/2017 à 11h06
Et l’intérêt d’avoir un code source visible ?
(Truequestion)
Le 26/06/2017 à 11h12
Le 26/06/2017 à 11h14
Cette tempête dans un verre d’eau… C’est pas l’impartialité qui t’étouffe.
Oui, la publication incontrôlée de source peut mener à des soucis de sécurité. L’intérêt d’une publication contrôlée des sources n’est pas de ne pas avoir de faille de sécurité mais d’être capable de les identifier (et donc de les corriger) rapidement. Dans ce cadre précis, et Vincent n’a pas utilisé de formule générique, c’est un potentiel problème de sécurité.
Après c’est Microsoft et c’est Vincent donc on va avoir toute la clique pour qui ça va être la fête du slip dans les commentaires.
Le 26/06/2017 à 11h20
Le 26/06/2017 à 11h28
Il y a une nette différence entre du code open source, où tout est organisé pour que les bugs et failles soient remontées/corrigées rapidement, et un leak sauvage où personne ne va rien remonter, parfois par peur des représailles.
La sécurité par l’obscurité est un principe qui peut fonctionner dans certains cas, tout dépend contre qui tu veux te protéger. Selon le niveau de protection de ton code, il faut parfois un groupe organisé voire même un gros budget pour arriver à faire le reverse engineering. Si tu acceptes de n’être protégé que contre les hackeurs du dimanche, l’obscurcissement de ton code est un outil comme un autre.
Le 26/06/2017 à 11h33
Non. La sécurité par obscurité ne fonctionne jamais.
C’est parce qu’on parle de windows que vous racontez de telles âneries ?
Et pour info, windows est l’OS majoritaire, il est très loin de n’être attaqué que par les hackers du dimanche… Et il faut, en tant qu’OS majoritaire, le protéger contre toutes les attaques…
La secu par obfuscation comme principe valable… On aura tout lu ici…
Le 26/06/2017 à 11h39
Y’a quand même un bon côté dans tout ça, Wine/Crossover devrait pouvoir profiter d’un meilleur support USB très prochainement, pour peu que les devs étudient un peu le code source de cette fameuse pile pour les pilotes pour bien en comprendre le fonctionnement… ;)
D’ailleurs pour le wifi, ça pourrait même profiter au noyau Linux côté drivers…
Ça serait drôle qu’un outil permettant de charger certains pilotes Windows sous Linux soit mis au point… (Je ne parle pas de Ndiswrapper qui dans les faits, ne charge que le firmware du chipset Wifi…)
Le 26/06/2017 à 10h08
Et la Microsoft fait passer Windows en open source.
" />
Le 26/06/2017 à 10h15
Cependant, les piles liées aux pilotes restent des composants importants, et la visibilité du code source pourrait entrainer des soucis de sécurité.
On t’a reconnu, jvachez " />
Le 26/06/2017 à 10h17
Beaucoup de buzz pour rien d’autre que le “Shared Source Kit” diffusé aux partenaires fabricants de matériel.
Le 26/06/2017 à 11h39
Merci, tu m’as évité de répondre la même chose.
Le 26/06/2017 à 11h46
dans tout ces avantages du code ouvert, il y en a un que vous avez oublié qui me parait le plus important, voire même la raison première de son existence :
améliorer le code existant, ajouter des fonctionnalités.
Le 26/06/2017 à 11h54
améliorer le code existant, ajouter des fonctionnalités.
Avec l’accès à tout le code, tu peux refaire un os?
Le 26/06/2017 à 12h10
Tout dépend de ce qu’on appelle ‘fonctionner’. Ça ne garantie rien, c’est certain. Par contre ça rend effectivement le travail plus complexe pour ceux qui voudraient trouver des failles.
La question n’est pas ‘est-ce que c’est la sécurité parfaite’ (évidemment non), c’est plutôt est-ce que l’obscurité handicape plus les gentils ou les méchants (j’ai ma petite idée sur la question).
Le 26/06/2017 à 12h20
Heuuu sisi… (attention mon exemple ne parle pas du code accessible mais de “sécurité par l’obscurité”)
Exemple : par principe tu demandes à tes application web de ne pas afficher le numéro de version (on évite de dévoiler la version de Joomla, ou du apache derrière etc…)
Cacher des éléments = réduction de la facilité de l’attaque
Ce n’est pas une “sécurité ultime” c’est juste une réduction d’un vecteur d’attaque.
La sécurité c’est simple: “rien n’est infaillible, il faut juste mettre des batons dans les roues pour éviter que ce soit trop simple”. Quand le cout de l’attaque est inférieur au gain (ou au cout de risque), c’est une sécurité “acceptable”.
Cacher le code n’enleve pas la faille mais réduit sa facilité de découverte (mais engendre le non-audit libre etc…).
Reste le débat de “ce n’est pas parce que le code de l’appli est disponible que quelqu’un va aller rendre l’appli plus sécurisée (cela dépend de la criticité et de la popularité: cf va voir le nombre de lignes de codes pourries sur github).
Il faut que je retrouve les études qu’il y avait eu sur le sujet: pas de différence majeures en termes d’erreurs./failles entre coté privé et code public. Mais par contre meilleure réactivité des “codes pubics” de par leur pratique de prise en compte des bugs (comme dis par un autre commentaire plus haut)
Le 26/06/2017 à 12h44
Le 26/06/2017 à 14h00
Le 26/06/2017 à 14h10
Le 26/06/2017 à 14h11
Le 26/06/2017 à 14h13
:popcorn:
bon sinon faut en vouloir pour récupérer 32To de Windows " />
Le 26/06/2017 à 14h17
Le 26/06/2017 à 14h22
Je ne suis pas de ton avis, c’est tout simplement l’explication. Quand j’ai vu des commentaires suggérer des modifications avec lesquelles j’étais d’accord, je le faisais et je remerciais, avec le petit “" />” qui va bien pour marquer le coup. Ici, ce n’est pas le cas. Voilà, on ne va pas épiloguer là-dessus pendant des heures.
Le 26/06/2017 à 14h39
C’est chaud ici aujourd’hui !! On n’est que lundi les amis !! " />
Le 26/06/2017 à 14h46
Ben moi c’était une blague d’autant que je suis assez d’accord avec toi.
Le 26/06/2017 à 15h44
Le 26/06/2017 à 16h37
Le 26/06/2017 à 17h39
Le 26/06/2017 à 18h05
Le 26/06/2017 à 19h27
Intervenant rarement les commentaires, je rajoute juste un petit commentaire pour appuyer ton avis et ta démarche.
C’est tellement exaspérant de voir des mecs de ce calibre venir déverser leur prétention et leur agressivité dans les commentaires, persuadés jusqu’à l’os qu’ils sont des chevaliers blancs en armure alors qu’ils ne font que desservir leur cause ! On peut avoir des avis divergents et des opinions différentes , mais un peu de respect et de modestie n’a jamais fait de mal à personne, surtout vis à vis des journalistes qui essayent quand même de faire correctement leur travail.
Typique du barbu linuxien en armure obsessif qui croit naïvement qu’il va changer le monde en voulant imposer son idéologie par la force ( et le pire c’est que le libre a plein de qualités, mais ils donnent tellement l’impression qu’on va rejoindre une “secte” de tarés comme tu dis qu’ils arrivent à en refroidir les partisants les plus lambdas (comme moi) )
Le 26/06/2017 à 20h58
Le 26/06/2017 à 22h30
Le 27/06/2017 à 04h14
+1 Moi aussi tient!
(lecteur depuis 2006)
Le 27/06/2017 à 07h21
Le 27/06/2017 à 10h32
Le 27/06/2017 à 11h18
Quand tu veux sécuriser un service ou un produit, tu définis d’abord contre qui tu veux le sécuriser. Contre une attaque externe ? Interne ? En local ? Par le réseau ? Avec un accès matériel? Par un hackeur ? Par ton hébergeur ? Par un gouvernement ?
Se prémunir à 100% des failles, si tant est qu’on considère que c’est possible, demande beaucoup trop de moyens pour être un objectif raisonnable, surtout pour les petites boîtes.
L’obfuscation est une solution, c’est le niveau 0 de la protection, c’est loin d’être infaillible, mais c’est une solution. C’est d’ailleurs le principe utilisé dans tous les systèmes de sécurité basés sur des cartes à puce, c’est à dire qu’on fait en sorte qu’un accès physique à la carte à puce ne suffise pas, et il faut du matériel hors de prix et des compétences de malade pour espérer faire un reverse engineering sur une carte à puce.
Evidemment pour Windows, ce n’est pas une bonne solution, vu que c’est un OS majoritaire utilisé dans des domaines parfois très (trop) sensibles. D’un autre côté, sources fermées ne veut pas dire forcément plus de failles, tout dépend des moyens que tu met dans la conception de ton système.
Mais si les sources sont leakées alors qu’elles n’auraient pas du l’être, c’est une mauvaise chose. Vu que le leak n’est pas prévu, il n’est pas non plus vraiment prévu qu’il y ait tout le mécanisme habituel de l’open source avec merge request, review, etc etc. Donc au final potentiellement des failles qui tombent dans la nature et qui sont facilement accessibles alors qu’il aurait fallu un peu plus de boulot en temps normal si les sources avaient été fermées.
Le 27/06/2017 à 12h14
Parfois les attaques de la ‘secte’ sont pertinentes et approfondissent le sujet.
Ce que je méprise ce sont les attaques personnelles ou professionnelles.
Surtout dès le début des comms.
Là ça pourri tout et c’est très dommage.
La forme quoi, pas le fond.
Le 27/06/2017 à 12h57
Le 28/06/2017 à 19h45
Preuve en est que ce ne sont pas ceux qui parlent le plus qui disent les choses les plus intelligentes. C’est pour des commentaire comme ça qu’un système de points devrait être ajouter dans ces derniers.
Enfin, n’oublions pas que la drépanocytose reste une maladie au même titre que certains intervenants dans les commentaires … " />