pasBill pasGates a écrit 16062 commentaires

Entre les deux, il y a 500 millions d'instructions assembleurs.

Non mais tu te fous de moi…

Tu mets un breakpoint sur la fonction d'encodage, t'attends gentiment que les donnees arrivent dedans, et hop tu vois que c'est les favoris. Tu notes les addresses, tu suis.

T'as visiblement jamais entendu parler de taint tracking non plus.

Ca prend pas 3 minutes, mais c'est tres tres loin d'etre infaisable.

Franchement, s'il suffisait de suivre l'assembleur, comment tu expliques les difficultés pour le protocole utilisé par Skype pour être compris ? Une recherche sur "skype reverse engineering" montre que c'est très loin d'être une partie de plaisir.

Skype a ete construit de maniere specifique a etre difficile a decompiler et comprendre, et pourtant au final des gens y sont arrives (cf. les gars d'EADS: http://recon.cx/en/f/vskype-part2.pdf ca date de 2006, une paie !)

Exactement: c'est une question de croyance. Donc, quand quelqu'un dit "le code ouvert est bien mieux que le code fermé", tu dois lui répondre "ma croyance est différente de la tienne"

Croyance ? Tu m'excuseras. J'ai passe 10 ans dans le champs d'activite dont on parle ici (securite), sur l'OS dont on parle, avec les sources. Et tu veux venir m'expliquer que pendant 10 ans moi et mes collegues, dont certains sont des pontes reconnues dans l'industrie, on s'est fourvoye comme des idiots ? Un peu de serieux mon cher.

Comme démontré, dans un code proprio, il suffit de créer une faille intentionnelle, et si elle est découverte, les conséquences seront NULLES (à la limite, on vire 2-3 boucs émissaires qui n'étaient de toutes façons pas en position de dire quoi ce soit lorsque la backdoor a été mise).

Et c'est IDEM dans du code libre !

C'est illégal, mais passons.

En Europe ? J'en doutes. Meme aux USA, tu peux aller sur plein de sites de boites de securite et tu verras des extraits de code assembleur de DLLs Windows pour decrire differentes failles, aucun ne s'est jamais fait poursuivre.

C'est encore plus long et plus chiant que de simplement réimplémenter le compilateur et l'OS. Quel intérêt ?

Ben pas trop non, ca te garantit que le code binaire suit le code C/C++ que tu vois, ca t'affranchis du compilo et de l'OS. Chiant ? Si tu fais ca a la main evidemment, si tu automatises en te basant sur l'arbre d'execution decoulant du code C/C++ et que tu laisses ton systeme simplement te signaler les cas ou il a un doute dans sa comparaison assembleur/arbre, c'est pas trop complique.

Evidemment que quand tu veux verifier un OS, vu la taille, tu investis dans l'automatision du boulot, c'est pas un boulot purement manuel.

Compiler un OS avec un compilo different c'est une gageure a cause des extensions, Linux essaie depuis longtemps avec LLVM et de ce que j'ai compris, c'est toujours pas 100% fait.

Tout ce qui touche a AWS, ca va de Xen a Windows a Java et autres.

Compiler depuis un OS different certainement pas, une version d'OS differente oui.

Maintenant quand tu as le binaire, et que tu peux le decompiler sur une autre machine (non-Windows) pour comparer le code assembleur et t'assurer qu'il est equivalent aux lignes en C/C++, avoir toute la chaine est franchement inutile.

Tu VOIS que Skype fouine dans les favoris du navigateur. Tu VOIS que Skype se connecte avec un serveur central et transmet des informations codées. Montres moi le code assembleur où se trouvent la faille ?

Tu montres le code assembleur ou Skype lit les favoris, les encode, et les envoie. Aussi simple que ca. C'est irrefutable, tout le monde peut des lors verifier que ce que tu dis est vrai.

Tu ne réponds pas non plus sur ce point: je découvre une faille 0-day sur Windows. Je montre donc le code assembleur. Est-ce que ça implique que MS a collaboré avec la NSA ?

Evidemment que non, si c'est un simple buffer overflow. Maintenant l'exemple Skype serait une backdoor

Bref, montrer le code assembleur, ÇA NE SERT STRICTEMENT À RIEN.

Justement si, dans l'exemple Skype.

Pour la difficulté supplémentaire (j'imagine que c'est de ça que tu parles avec tes 5 minutes / 10 minutes), c'est bien beau de minimiser les points qui font mal à ta religion, reste que le code ouvert est forcément aussi bien et sans doute mieux que le code fermé.

Qu'il est aussi bien je n'en doutes pas, qu'il est un tout petit peu mieux je n'en doutes pas non plus, qu'il est bien mieux je ne le crois pas du tout.

Premièrement, l'important est que le client ait la possibilité de bouger facilement (s'il ne souhaite pas bouger, tant pis pour lui). Ce qui n'est pas possible sous Windows sans devoir repartir "from scratch". Si tu te formes pour gérer des Windows ce que tu as appris ne peut être utilisé QUE si tu utilises des outils MS. Si tu te formes pour linux, quitter Redhat ne posera aucun problème.

Quitter Windows revient a changer totalement d'OS oui, maintenant le jour ou il y a une backdoor dans le noyau Linux (on est dans l'hypothetique toujours), j'attends de voir a quoi les forks font ressembler, a quel point il y aura incompatibilites avec l'existant au bout d'un an ou deux, etc… Tu n'as aucune assurance que les choses iront bien.

J'en ai. Clamer qu'un code mal écrit doit être réécrit, que faire de la sécurité c'est aussi écrire du code propre, que faire du bon design et bien coder est essentiel, ce n'est pas 'manquer d'humilité'.

Ton probleme c'est que tu clames que le code est mal ecrit en ta basant sur une analyse foireuse.

Windows est arrivé la ou il en est majoritairement car il y a d'excellents commerciaux qui bossent (ou qui bossaient) chez Microsoft, pas parce-que ce truc était innovant ou bien écrit.

On va dire que c'est du foutage de gueule de dire que l'OS le plus vendu de la planete pendant 20 ans ne l'a ete que grace a des excellents commerciaux.

Je n'adhère pas aux arguments d’autorités. Et vu les APIs Windows bas niveau, ce n'est pas du tout bien architecturé, mais alors pas du tout, de mon point de vue.

Ah ben vas-y, decris moi les problemes de l'API Windows bas niveau et explique moi en quoi ils sont problematique.

Si l'explorateur fichier de Windows est [nécessairement] incroyablement complexe, alors je doute sérieusement de la compétence des personnes qui ont architecturé le système. Sous Linux, des explorateurs simple qui font bien leur boulot comme Thunar ne sont pas incroyablement complexe.

Non visiblement tu ne comprends pas le probleme, ton explorateur de fichier qui est 'simple', il fait appel a d'autres librairies, c'est librairies elles font partie des chemins d'execution, elles sont prises en compte dans l'analyse statique. Tous ces etages forment ton chemin d'execution.

Faisons simple :

Pour installer un de ces modules crypto, il faut etre admin, et NT4 n'a jamais eu de 'windows update', l'install est a faire manuellement en admin.

Si t'es admin, tu peux bypasser le check de signature tres simplement sur NT4, donc pas besoin de signature forgee.

Resultat, si la NSA voulait 'discretement' installer un module crypto, elle devrait etre admin sur la box a la base, ce qui rend l'utilite caduque.

L'autre cas est ou la NSA convainc un utilisateur d'installer un module crypto signe par ses soins, on va gentiment dire que si ils arrivent a faire ca, ils ont 432 autres moyens qu'un module crypto pour prendre le controle.

Alors doute oui, il y aura toujours doute, tout comme on peut avoir un doute sur toutes les clefs et certificats controles par MS, aucune difference. Mais dans ce cas precis, l'utilite est tellement faible en matiere d'exploitation que c'est un peu risible.

Donc, en prenant une faille 0-day qui vient d'être annoncée, je peux montrer un code qui utilise cette faille.
Donc, c'est irréfutable: je viens de prouver que MS a collaboré avec la NSA.

T'as prouve qu'il y avait une faille. Si le code que tu pointes dans Windows se connecte tout seul a un serveur et uploade tes fichiers, on peut directement dire que c'est une backdoor. Si il ouvre un port avec un shell derriere, on peut directement dire que c'est une backdoor. Si c'est juste un buffer overflow, tu peux directement dire que c'est une faille, etc…

Fais pas expres d'etre stupide.

C'est ce que je me tue à te dire: la différence n'est pas dans la preuve de la backdoor ou pas, la différence, c'est qu'on peut changer de développeurs quand on perd la confiance.

Mais tu peux changer d'OS mon cher, t'es pas oblige de rester sous Windows.

Avec Apple, la question était de savoir si les données contenaient un identifiant qui permettait de le relier à l'acheteur. Il suffit de faire "codage avec une clé spécifique(id de l'acheteur + nombre aléatoire)" et il est IMPOSSIBLE de différencier ça d'un ID purement aléatoire en interceptant les données

T'as visiblement jamais fait de reverse engineering. Tu interceptes le traffic, tu vois cet ID, tu remontes pour voir d'ou il vient.
Et tu verras qu'il encode l'id de l'acheteur.

Plus simplement: dans ce cas, tu n'as qu'à me détailler le contenu de ces données. Personne n'a pu le faire.

Tu m'excuseras mais j'ai autre chose a faire qu'attenuer tes peurs vis a vis d'iOS. Ce n'est pas parce que personne n'a pu le faire que ce n'est pas faisable, et ce n'est pas parce que personne ne l'a fait qu'il y a un truc douteux.

Et des failles critiques, il y en a partout dans tout les programmes. Si une faille critique serait suffisant pour "donner un coup a l'economie US en represailles", les USA seraient déjà dévastés.

Tout a fait

Comme je me tue à le dire: on ne peut pas différencier une faille critique d'une backdoor. Là n'est pas le problème. Le problème, c'est qu'en cas de perte de confiance, si tu veux continuer à utiliser Windows, tu es obliger de faire confiance à Microsoft.

Comme tu le dis, impossible de differencier. Tu vas baser ta confiance sur quoi alors si aucune backdoor n'est trouvee (vu que ce sont toutes des failles potentiellement) ?

La regle est simple en passant: t'as pas confiance en MS, n'utilises pas Windows.

a) Tu attaches un debuggeur sur le soft en question (il tourne sur ta machine hein, c'est plus que facile), tu interceptes l'appel de lecture ou ecriture sur le socket SSL, tu regardes les donnees. C'est de loin le plus simple

b) Tu ajoutes un root certificate sur ta machine que tu controles, tu interceptes le traffic en man-in-the-middle en repondant avec un cert issue par ta root authority, tu regardes ce qui passe. En debuggant tu peux facilement voir si le code prend un chemin different selon le certificat pour t'assurer que le code ne detecte pas une root authority differente et fait qqe chose de different.

Quand c'est sur ta machine, tu controles tout, c'est hyper simple de voir ce qu'elle fait.

Tu me fais marrer, tu demandes de prouver l'innocence du code.

Tu veux quoi, un suivi des 500 millions d'instructions assembleur ?

Tu vois une faille/backdoor, montre la, pointe le code assembleur, montre en quoi il fait qqe chose de mal. Tu ne peux pas ? Alors comment oses-tu dires que c'est une backdoor ?

En tous cas les ingénieurs Microsoft côté Windows ont choisi d'implémenter ce standard, inefficace à la base (du retraitement d'aléa de type asymétrique pour un truc que tout le monde fait avec des méthodes du monde de la crypto symétrique, non mais franchement !), et qui s'est avéré troué.

LOL, ca oui c'est plus complique, plutot que passer 5 minutes faudra en passer 10.

Bref, une backdoor chez MS profite à MS avec pratiquement 0 inconvénients (car même si on la découvre, on dira que c'est une faille et puis c'est tout, les utilisateurs ne bougeront pas pour ça). Une backdoor dans un système open source ne profite qu'à une petite poignée de contributeur et a plein d'inconvénient (car même si on prétend que c'est une faille, le résultat est que s'il reste un soupçon, les clients migreront facilement et les réputations seront entâchées. Ça implique que les contributeurs qui ne profitent pas de la backdoor sont d'autant plus poussés à vérifier qu'elle n'existe pas car si elle existe, ils perdent beaucoup sans avoir rien gagné en échange).

Une backdoor chez Redhat profite a Redhat avec pratiquement 0 inconvenients (car meme si on la decouvre, on dira que c'est une faille et puis c'est tout, les utilisateurs ne bougeront pas pour ca)

Marrant comment ca marche des 2 cotes.

Il est audite et auditable, simplement pas par tout le monde.

Ces 2 chercheurs ont implemente la plus grosse partie de la stack crypto de Windows, chose que visiblement tu as un mal fou a accepter.

Tu vas sur leur profile LinkedIn, tu verras que les 2 ont notamment "Software Development Engineer" dessus, pas simplement "Researcher". Mais fais seulement, expliques moi comment mon ancienne boite fonctionne…

En tous cas les ingénieurs Microsoft côté Windows ont choisi d'implémenter ce standard, inefficace à la base (du retraitement d'aléa de type asymétrique pour un truc que tout le monde fait avec des méthodes du monde de la crypto symétrique, non mais franchement !), et qui s'est avéré troué.

Ils l'ont implemente, car partie d'un standard federal et que pour vendre au gouvernement il faut qu'il soit la, mais ne l'ont jamais mis 'on' par defaut. Resultat, seuls ceux qui le voulaient l'avaient.

Justement, le propos était de dire : sans code source, se serait encore pire. Je n'ai jamais dit que c'était simple, très très loin de la. Mais avoir les sources est un avantage vraiment non négligeable.

a) Cela ne l'est pas. 10 ans d'experience dans le domaine sont assez clairs la dessus.
b) Meme en imaginant que ce soit mieux, cela ne satisferait pas nombre de gens car cela n'est pas 100% sur et donc pas prouvable, car ces gens se foutent de la realite, ils croient ce qu'ils veulent : qu'il y a des backdoors.

Si c'est vraiment le cas, alors le code est très certainement de très mauvaise qualité. La bonne manière serait plutôt de réécrire les parties pourries pour qu'elles soient facilement analysable et maintenable. Plus c'est simple et bien pensé, moins il y aura d'erreurs grave. C'est aussi ça, faire de la sécurité.

Non mais vraiment… Je te suggeres un minimum d'humilite mon cher. Faire de l'analyse statique sur un OS, ou tu as couche apres couche de librairies, c'est pas comme faire de l'analyse statique sur un soft de 10'000 lignes.
Windows n'est pas arrive la ou il est en etant une merde ecrite par des developpeurs incompetents, le code est lisible et maintenable pour son enorme, enorme majorite (toujours des exceptions ici ou la). L'OS a ete architecture par des gens qui sont des experts, le developpeur moyen chez MS est au dessus de la moyenne, et ils ont des outils d'analyse qui sont loin devant la plupart des autres boites.

Simplement un OS est une bete extremement complexe et large. Si tu veux faire l'analyse statique de l'explorateur de fichier lors d'acces a des fichiers par reseau par exemple, tu te retrouves a avoir une analyse de l'arbre d'execution qui va sur des etages entiers. C'est incroyablement complexe, selon les branches tu ne peux pas avoir une limitation des contraintes sur les variables connue a 100% ce qui t'amene soit des warnings qui sont au final faux soit une presomption que ce n'est pas un probleme alors que cela pourrait en etre un. Idem pour un browser web et tout autres soft un tantinet complexe, et un OS ca en regorge.

À mon avis, y'a bien plus que 700 ou 7 000 personnes, l’ordre de grandeur serait au moins de 70 000. Ce n'est pas le même ordre de grandeur.

70'000 mais tu reves mon cher. 95% des 'consultants securite' de la planete sont des clowns qui savent principalement lancer un outil auquel ils ne comprennent pas grand chose et en faire un joli rapport. L'enorme, enorme, majorite des developpeurs n'ont pas idee de ce qu'est une faille en securite.

Pour exemple, on va prendre Win32k.sys, un des elements les plus friables de Windows au niveau securite. Essayer de comprendre le fonctionnement de ce driver avec les sources est une gageure, le code est complexe, difficile a reecrire sans tout casser, et il a pris tellement de security reviews que tout ce qui est visible facilement est tombe.

Quelqu'un qui veut y trouver des failles en lisant le code devra d'abord passer au minimum 6 mois rien que pour comprendre l'architecture du bousin, comment il fonctionne, et ou passent les donnees. Ensuite il devra se mettre a lire des dizaines de milliers de ligne de code, ecrites pas super proprement(eh oui, c'est vieux), mais qui ont deja ete auscultees par toutes les grosses boites securite contractees par MS, par les ingenieurs securite de MS, par les developpeurs de MS qui ont ete entraines sur les concepts securite, et par des chercheurs en securite externes qui ont ete attires ces 10 dernieres annees par la publicite qu'une faille la dedans amene.

Bonne chance. si tu as un an de ta vie a depenser pour cela, sans garantie de retour sur investissement fais seulement. Perso avec mes 10 ans d'experience, y inclus ce composant precis, j'utiliserai une autre approche.

Tu multiplies ton effort par 7 000 et tu comprendra que c'est là la différence entre une équipe de 10 mecs qui sont dessus et une communauté qui regarde de temps en temps le code, sur la durée.

10 mecs ? LOL… C'est la ou tu ne te rends pas compte a quel point tu es a cote de la plaque.
Microsoft a une chose pour laquelle il est connu dans l'industrie soft : SDL (si tu ne sais pas ce que c'est, je t'invites a aller te renseigner, c'est important…)
Tous les developpeurs et testeurs de la boite passent a travers les trainings pour cela, c'est un peu une obession dans la boite depuis l'epoque 2002-2003 et Code Red.
Resultat, le developpeur/testeur moyen chez Microsoft est largement au dessus du developpeur moyen dans l'industrie au niveau connaissances en securite. Je vois ca dans mon nouveau job et c'est vraiment flagrant.
Tu rajoutes a ca le fait que Microsoft a des outils d'analyse et d'attaques qui sont loin devant ce que le reste de l'industrie a (va voir ce que SAGE est, ca fait pas loin de 10 ans que MS a ca, il n'y a toujours rien d'equivalent de disponible publiquement)
Ensuite tu rajoutes l'attractivite de Windows aux yeux des chercheurs en securite du fait de la base installee et de la pub qu'une faille dans Windows amene.
Resultat, le code de Windows (et autres softs MS) a largement plus que 10 yeux dessus niveau securite, il a problabement ete bien plus ausculte qu'a peu pres n'importe quel code sur cette planete.

Très très discutable. Je serait plus d'avis de dire que les chercheurs en sécurité, les pirates, les programmeurs sont aussi des personnes compétentes, au même titre que les gouvernements. C'est peut être une histoire de culture alors.

Les chercheurs en securite oui. Les pirates (gars qui copient des softs illegalement donc) non certainement pas, les programmeurs certainement pas non plus dans leur enorme, enorme, majorite. La plupart ne savent meme pas ce qu'est une faille de securite.

Hein ? Où ça ?

Ici : " Et puis c'est pas comme si les backdoor c'est simple à trouver dans un code qui fait des dizaines de million de ligne (juste pour Windows), avec des couches de partout"

Il y a trouver des failles en testant au hasard et en analysant du code désassemblé, et il y a trouver des failles en testant au hasard et en analysant le code source. Il y a pléthore d'outil qui analyse statiquement du code C ou du code plus compréhensible que de l'assembleur et qui permettent d'orienter efficacement les recherches.

Tout a fait, le truc etant que Windows a deja passe 10 ans dans ces softs d'analyse statique. Dans l'etat actuel, soit tu prends un de ces softs, les mets en 'noisy' et tu te tapes 500 warnings pour 1 bug reel ce qui est une gageure au niveau revue des resultats, soit tu y vas de maniere externe.

C'est à dire ?

Fuzzing, outils qui analysent le comportement d'une connection TLS, outils qui font du monitoring/interception d'acces fichiers/registry/… etc…

Dans ce cas, pourquoi y a-t-il eu la controverse _NSAKEY ou des données nocturnes de l'iphone ?

Controverse ? Mais controverse chez qui ? Chez les pekins de linuxfr qui veulent y voir ce qu'ils veulent oui.

Dans la communaute securite tout le monde a rigole car il etait vite vu que c'etait de la merde en boite qui n'avait aucune signification de point de vue de la securite

Parler de preuve est STUPIDE: il sera toujours impossible, que ce soit un code ouvert ou fermé, de prouver qu'une backdoor intelligemment placée est une backdoor intentionnelle ou une faille critique.

Exactement. Tu viens de demontrer pourquoi ouvrir le code ne changera rien. Meme en imaginant que la NSA ait un controle total sur les source de Windows, ils sont pas cons, ils n'insereront jamais une backdoor qui ressemble a une backdoor.

Lire les sources de Windows ou Linux a la recheche de backdoor c'est une connerie, c'est impossible. Comme je l'ai dit plus bas, les sources ouvertes pour eviter les backdoors, c'est de la connerie marketing et rien d'autre.

Si ça avait été le gouvernement chinois ou russe tout le monde aurait crié à la tentative de manipulation et aux documents falsifiés (franchement, si la Chine te propose 4-5 transparents powerpoints, tu vas en conclure que c'est une preuve ?).

LOL, mais si c'est une backdoor dans l'OS, pas besoin de powerpoint, le code est la, sur la machine de monsieur tout le monde, la verification est claire, nette et sans aucun doute !

Donc, il suffit à la Russie ou la Chine d'ouvrir notepad et d'écrire une backdoor dans le code, et ça y est, voilà la preuve que MS a une backdoor.
Quant à pointer du doigt du code compilé, il suffit de choisir un morceau qui a l'air suspect comme il y en a dans tout les logiciels conséquents.

Un morceau qui a l'air suspect ? Mais mon cher, une faille/backdoor, ca l'est ou ca ne l'est pas. C'est pas 'suspect'. Tu peux montrer comment elle est utilisee/exploiter, c'est irrefutable a ce moment la.

Pareil pour une procédure d'exploitation de la backdoor: MS répondra: c'est une faille critique (et pourra p-e même porter plainte pour avoir dévoilé la faille alors que le contrat qui va avec le code l'interdit, par exemple).

Deja, si c'est demontre a l'aide de code decompile, nul besoin de code source, aucun contrat de viole.
Quand a dire que c'est une faille, oui tout a fait, mais c'est idem sous Linux. Quand une faille critique est trouvee dans Linux, tu sais si c'est une backdoor qui avait ete inseree consciemment ou une faille innocente ? Non evidemment.

Détails techniques impossible à vérifier.
Par exemple cette histoire de données transmises par l'iphone pendant la nuit. Apple a justifié ça comme étant des données anonyme utiles, mais personne (à ma connaissance) n'a réussi à prouver quoi que ce soit sur le réel contenu et le réel fonctionnement de ces données.

Tu te fous de moi. Les donnees transmises tout le monde peut les voir, il n'y a AUCUN probleme a intercepter la transmission de donnees sur un canal SSL et le voir non-encrypte, c'est le BA-BA de la securite informatique ca.

Quant aux choux gras de la presse: elle en a fait plein sur cette histoire d'iphone ou de _NSAKEY. Conséquences ? Aucune !

Normal, dans les 2 cas c'etait une anerie.

Si demain la Chine ou la Russie fait une telle déclaration, tu seras le premier à rigoler en disant que c'est évidemment une lamentable tentative de FUD (preuve que la Chine et la Russie seraient idiots de se lancer dans la solution 1).

Si les details techniques sont la, c'est irrefutable. C'est au minimum une faille critique, au pire une backdoor.

Tu es entrain de dire que une personne sur 100 millions d'humains est capable d'identifier une backdoor dans le code de Windows. En gros, qu'il y a à peu près 70 personnes sur terre qui peuvent le faire.

Enleves un zero si ca te fait plaisir, c'est l'ordre de grandeur.

Mais supposons que c'est vrai, cela voudrais dire en réalité que les sources de Windows sont totalement impénétrable, que c'est un immense plat de spaghetti. Dès l'instant ou Microsoft ouvrirait ses sources, les critiques pleuvraient et Microsoft serait grandement discrédité, il y aura de grande chances pour qu'un mouvement de masse de migration s'enclenche.

Non, ca veut simplement dire que tu n'as visiblement jamais eu a faire de la recherche securite sur un systeme de cette taille, sinon tu comprendrais a quel point c'est une gageure de revoir le code d'un systeme pareil. Tout comme avec une distrib Linux.

Mais bon, c'est de la pure spéculation, comme tes pseudo-statistiques de détection de failles.

Mes pseudo-statistiques sont basees sur le fait que mon boulot, avec de nombreux autres collegues dont certains sont la creme de la creme dans l'industrie securite, a ete precisement de trouver des failles dans cet OS, alors que j'avais acces aux sources, pendant 10 ans.

On avait acces illimite aux developpeurs, a des docs, … et l'approche sans revue de code a toujours ete la plus efficace. Le code est utile pour comprendre la faille une fois que tu l'as trouvee, c'est a peu pres tout le plus souvent.

Et devines quoi, bizarrement, ce paragraphe est toujours vrai alors que maintenant je bosses sur des systemes qui le plus souvent n'ont pas un seul rapport avec Microsoft de pres ou de loin.

Besoin de montrer le code ?

Ce code il est compile dans un binaire, que plus d'un milliard de gens ont sur leur machine.

Tu prends ce binaire, tu le decompiles, tu montres etape par etape comment la backdoor fonctionne en suivant l'assembleur, sans jamais avoir besoin d'afficher une seule ligne de code source.

Exactement comme cela se fait tous les jours pour des failles trouvees.

Encore faut-il qu'ils soient compétent, et qu'ils aient accès au même source que celles qui ont servit à vendre Windows. Les gouvernements sont des "organismes qui sont de confiance pour le public", et pourtant… L'argument ne tient pas, si l'on souhaite être transparent, ont ne donne pas les sources à des privilégié, mais au public, sinon c'est de la mauvaise foi.

L'argument tient totalement. Les gouvernements sont parmis les rares groupes competents pour juger de la securite d'un programme.
Si on veut etre transparent pour des raisons marketing, oui, il faut donner les sources a tout le monde, meme si on sait tres bien que quasiment personne ne les touchera, que parmis ceux qui les toucheront, tres peu sont capables d'y comprendre qqe chose, et que meme parmis ceux qui sont competents, il y a tellement de code que c'est une gageure.

Je ne pense pas que c'est ce qu'il se passera, néanmoins, il y a un monde entre diffuser les sources aux privilégiés et ouvrir les sources au public. Ce que tu dis la est purement de la spéculation.

Ce n'est pas de la speculation, c'est ce qui se passe ici, ce que tu as exactement fais toi-meme qqe posts plus haut.

C'est totalement faux et sans fondement. Je rêve d'aller mettre mon nez dans les sources de l'OS utilisé par 90% de la population, et je suis certainement pas le seul.

Super, tu entreras alors dans la section des 'quasi personne', et tu auras beau mettre ton nez dedans, les chances que tu y deceles des failles/backdoors simplement en lisant le code sont infiniment faible en comparaison d'autres techniques ne demandant pas le code.

Eradique Windows ? Mais tu reves mon cher.

Deja il faut lire l'article. Tu y verras que la Chine fait cela comme moyen de pression car ils n'apprecient pas que MS ait arrete le support de XP.

Ensuite tu decouvriras que la Chine n'a vise que Windows 8, pas Windows 7.

Quand à rajouter une backdoor, ça serait relativement pas discret, vu que Red Hat distribue le code source ( sauf à violer la GPL ) des logiciels. Il serait aussi plus efficace d'aller directement upstream.

Tu crois que distribuer le code source va empecher l'insertion d'une backdoor ?

Et bon, on noteras aussi que Red hat ( ni même les autres fournisseurs de systéme d'exploitation libre, à l'exception de Google ) n'apparaissent dans une liste publié par Edward Snowden.

Tout a fait, car au niveau services ils sont inexistants.

Donc mon hypothése est que la NSA s'est surtout focalisé sur les actions directs et ciblés sur les données via les fournisseurs SaaS que sur les logiciels, ne serais que parce que c'est moins couteux, bien plus facile à justifier et moins risqué.

Tout a fait

Donc c'est bien tenté de mettre tout le monde dans le même panier, mais c'est pas le cas.

Justement si. Tous les fournisseurs de services sont dans le meme panier, tous les fournisseurs d'OS sont dans le meme panier aussi

Ben moi, je ne fais pas confiance aux gouvernements.

Pas besoin de croire qu'ils sont gentils, c'est pas le but. Simplement que leur interet s'aligne avec le tien sur ce sujet.

Oui, parce que les "gouvernements étrangers" (sous-entendus, étrangers aux USA si je comprends bien) sont connu pour leurs couilles énormes pour faire face aux autres puissances, grandes, petites ou moyennes. Il n'y a qu'à voir comment on a fait plier le Qatar, la Chine, la Russie, etc. en faisant passer les droits de l'homme avant le commerce international ou autres intérêts "stratégiques" (comprendre que le péquin moyen ne peut appréhender)

Tu as bien fait de mentionner la Chine et la Russie. Personne n'est arrive a les faire plier. Et devines quoi, ils ont les sources, et ils sont pas trop pro-US

Ce genre de discours de la part d'un état a uniquement pour but de manipuler l'opinion publique, et est un combat de popularité.

Mais evidemment que c'est pour l'opinion publique, mais regarde ce que Snowden a fait, cela a un impact certain sur l'opinion, et sur les societes US.

Surtout que personne ne peut rien prouver (car les preuves peuvent être créées de toutes pièces)

Justement non, si la backdoor est dans le code, tu peux la montrer clairement, contrairement a un service en ligne.

Si la Chine ou la Russie dit que MS espionne, les pays occidentaux vont avoir tendance à soupçonner la Chine ou la Russie de vouloir discréditer les USA.

Si les details techniques viennent avec alors non, ce sera plutot clair et net et la presse en fera ses choux gras.

FISA, USA PATRIOT Act, Calea, etc. ça ne suffit pas !

Non ca ne suffit pas, aucun de ces textes ne stipule qu'une backdoor doit etre installee dans les systemes d'exploitation.

L'affaire de la _NSAKEY en est certainement un exemple (d'ailleurs, elle existe toujours, elle a été simplement renommée!)

LOL ! C'est quoi cette affaire dis moi donc ? Allez, si c'est une backdoor cela devrait etre simple de prendre les binaires de l'epoque et demontrer comment l'exploiter !

Il y a aussi l'exemple de SKYPE qui a été modifié pour permettre les écoutes dites "légales".

Oui, c'est une obligation legale. Mais devines quoi, fournisseurs de service et operateurs de telecommunication, c'est pas la meme chose qu'editeur de soft.