pasBill pasGates a écrit 16349 commentaires

Et le type qui crée une backdoor va faire en sorte que ça soit facile ? Comme je le disais: tes arguments ne marchent que si le type qui crée la backdoor est un abruti fini.

Bien sur que non, ca ne veut pas dire que c'est impossible.

T'as remarque que depuis 20 ans les editeurs de jeux mettent des protections de plus en plus abracadabrantes et qu'a chaque fois elles se font exploser ?

Merci de donner un lien d'une présentation d'un type qui confirme que tu as tort.

C'est bien, heureux de voir que tu es bloque en 2006.

http://skype-open-source.blogspot.com/

Ah marrant, il a reverse engineere quasiment entierement le protocole Skype…

En quoi ce fait te donne-t-il la moindre légitimité sur l'évaluation de la difficulté de procédure dans un environnement dont tu ne connais pas le fonctionnement ?

Quel environnement dont je ne connais pas le fonctionnement ? Le monde libre ?

Mysql -> MariaDB, OpenSSL -> LibreSSL, GnomeShell -> Xfce pour BIEN MOINS QUE ÇA.
Tu as beau répéter ça sur tout les tons, le fait est qu'avec du libre, le code est séparé du développeur et ce n'est pas le cas avec le proprio.

Mais mon cher, si je suis developpeur MySQL et j'inseres une faille intentionnelle dans MySQL. Il ne se passera rien si elle est trouvee.
Tout le monde pensera que c'est une faille tout simplement, car je suis pas idiot, je vais pas mettre un commentaire au dessus disant que c'est une backdoor, et je vais pas faire un system("ssh monserver a moi") non plus, et tout le monde continuera a l'utiliser.

Comme je le disais : IDEM

Je ne t'encourages a rien du tout, je te dis que tout le monde le fait dans l'industrie securite et personne n'a jamais ete poursuivi pour cela, alors que MS le voit tout le temps.

Pour le probleme indecidable, oui tout a fait, maintenant on est pas dans la theorie ici ou on doit ecrire le systeme parfait, tu ecris un systeme qui t'apporte des garanties suffisantes.

Filer le code source du compilateur suffit ? Seulement si tu fais un audit de ce compilo, qui est une tache enorme elle meme.

La derniere faille d'OpenSSL n'a pas ete decouverte a l'aide du code, elle l'a ete grace a l'inspection de traffic reseau lors de tests.

Ensuite, je pense que l'idée même d'agent dormant est toxique.

Toxique parce que ça ne peux qu'aboutir à moins de collaboration à terme, et c'est exactement ce que Assange a tenté de faire avec Wikileaks

Tout a fait, mais il faut etre realiste. Des agences comme la NSA, le KGB, la DGSE, etc… ont un job. Elles vont faire ce job, peut importe l'impact que ca a sur le libre, sur MS, etc… en grande partie (il y a des limites j'imagines, mais certainement pas la ou on le voudrait).

L'agent dormant est tout simplement logique comme methode. Il y a 3-4 ans, un groupe d'agents russes se sont fait jete hors des USA, un de ces agents a un moment etait dev chez Microsoft… Tu crois qu'il est irrealiste qu'ils fassent de meme sur le noyau Linux, sur Apache, etc… ? Bien sur que non, ce sont des cibles de choix.

Serieux, si t'as un exploit local, quel interet d'installer un moteur crypto ? T'installes un rootkit et tu as controle complet sur la machine, tu peux t'inserer dans tous les processus, cacher ta propre existence, hooker la stack TCP/IP, lire ce qui arrive sur tous les sockets en clair, enlever le check de signatures pour les moteurs crypto et le faire afficher que tout est ok tout le temps, etc…

Pour NT / Windows c'est evidemment bcp plus simple que pour iOS ou Windows Phone / Android vu le manque de lockdown. Ca ne rend pas la chose impossible loin de la.

Des professionels (= boites de securite, etc…) ouvriront le phone, et s'insereront directement sur le bus et c'est regle.

Les seuls systemes qui se protegent contre cela sont des devices genre XBox et PS4.

Si tu veux faire une backdoor, tu as 2 choix. Soit tu fait un truc générique pour tout le monde, et je pense que oui, certains clients vont voir que le code fait pas la même chose que le binaire. Soit tu fait un rpm pour un client spécifique et tu lui donnes, mais du coup, ça implique de mettre vachement plus de gens au courant ( genre l'équipe QA qui va devoir tester la backdoor, l'équipe support qui va devoir savoir quoi répondre, les gens qui gèrent les miroirs, etc ). Et ils sont pas tous aux USA, loin de la pour des questions évidentes de support 24/7.

Gni ?

Tu veux inserer une backdoor, tu mets une faille volontairement dans le code, et c'est tout. Tu ne le dis a personne, certainement pas a ton QA ni a ton support.
Si qq'un la decouvre(y compris ton propre QA hein), ben tu fais un patch de securite bien entendu, et dans une prochaine update(peut-etre pas celle qui suit immediatement, un peu apres potentiellement) tu mets une autre faille.

Faire quoi que ce soit d'autres serait absolument stupide, et cela que le code soit ouvert ou ferme.

il y a des jailbreaks pour differentes versions d'iOS, possible pour qui veut.

Quel rapport ?

C'est totalement faux. Un juge ne peut pas creer de lois simplement en rendant un jugement.

Il peut decider qu'une loi est illegale par exemple, mais il ne peut pas en creer de nouvelles.

Ca serait de toute facon impossible a appliquer, car la seule chose contre laquelle une entite ou personne peut etre juge est les textes de loi (federal ou par etat), hors un jugement par un juge ne va pas changer ces lois, seuls le Congres et le Senat (federal ou par etat) peuvent le faire.

http://www.reuters.com/article/2014/05/20/us-microsoft-china-idUSBREA4J07Q20140520

The official Xinhua news agency said the ban was to ensure computer security after Microsoft ended support for its Windows XP operating system, which was widely used in China.

Preuve que c'etait en rapport avec XP et rien d'autre

"We have been and will continue to provide Windows 7 to government customers. At the same time we are working on the Window 8 evaluation with relevant government agencies," Microsoft said.

Preuve que c'est limite a Windows 8 et pas Windows 7

Si tu as quoi que ce soit de serieux qui demontre qu'ils veulent bouger loin de Windows en general, et que c'est du a autre chose que la fin du support de XP, il faudra donner du solide pour le demontrer…

On parle ici de gens qui publient le code assembleur d'une faille.

Il y a des dizaines et dizaines d'exemple d'exactement ca, a la virgule pres. Aucun ne s'est jamais fait poursuivre.

C'est publique, tout le monde le voit, MS y compris, ils le savent, et ont directement interagit avec les auteurs sans jamais les menacer ni les poursuivre.

Donc clairement, personne n'a peur de se faire poursuivre, plein de gens le font. Utiliser ca comme excuse pour dire "ils ne le feront pas pour eviter des poursuites" est une excuse a la con.

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.