pasBill pasGates a écrit 16057 commentaires

  • [^] # Re: La classique erreur de comparer matériel et immatériel...

    Posté par  . En réponse au journal Est-ce que RMS raconte "des idioties basées sur des prémisses qui n'ont plus cours" ?. Évalué à -2.

    Entre patcher un logiciel et un avion, il y a des mois de travail, de modélisation, et un coût colossal qui sépare les deux. Puis en informatique le patch s'applique immédiatement avec retour en arrière immédiat si besoin, un avion nécessite une immobilisation se chiffrant en semaines.

    Tu penses que cela coute combien de patcher les logiciels qui s'occupent de la navigation, des moteurs, etc… dans les avions ?

    Tu penses que cela coute combien de tester un patch sur disons la stack reseau d'un OS utilise par 500 millions de personnes, histoire qu'il ne merde pas dans 1% des cas et mette un million de machines a la rue ?

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 1.

    Ah oui tiens, j'avais pas pense au fait que tout etait dans le SoC :/

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.

    Ça fait des heures et des heures que j'explique qu'on ne sait pas voir que la faille et normale ou pas et que c'est ça la différence entre le libre et le proprio.

    Un buffer overflow est un buffer overflow, dans le libre ou le proprio le code sera le meme. Tu m'expliques comment tu arrives a voir dans un cas que c'est une faille 'pas normale' et pas dans l'autre ?

    Ajouter une faille est alors très difficile. Par exemple, on a un complice chez Redhat. Il ajoute la faille. Les types de Ubuntu, Suse, etc … jettent régulièrement un œil sur ce qui change chez Redhat parce que s'ils améliorent quelque chose, ça le intéresse. Du coup, un ajout suspect sera dénoncé par eux, d'autant plus que cela fera une bonne pub pour eux et une mauvaise pub pour un concurrent.

    N'importe quoi. Deja il faut que l'ajout soit 'suspect', plutot qu'un bug innocent. Ensuite une 'mauvaise pub' est une mauvaise pub pour tous les Linux, et ca pourrit la collaboration a l'interieur des projets si ils se mettent a pointer du doigt.

    Ajouter une faille n'est certainement pas tres difficile non, la preuve : plein de failles sont trouvees dans les diverse projets, bien apres qu'elles aient ete inserees, et elles n'ont pas ete trouvees par les mainteneurs de Ubuntu/Suse/…

    Si t'insères une faille dans le noyau, tu recevras des commentaires de types de chez Intel, Redhat, SystemD, … te disant: "hé, pourquoi vous avez fait cette modification non justifiée. on doit faire du code qui marche avec le noyau, donc, on vérifie que les modifications sont compatibles avec nous, et cette modification n'a pas de sens."

    Oui bien sur. Dans quel monde tu vis dis moi ?
    Les failles qui sont corrigees chaque mois dans le noyau, qui pour certaines etaient la depuis des annees, tu me dis si ce sont des failles innocentes ou des backdoors ?
    Ah oui tu ne peux pas.
    Comment elles sont entrees dans le code dis moi ? Parait que les gars de Redhat/Intel/SystemD les trouvent vite fait selon toi.

    Si tu l'insères dans Firefox ou KDE/Gnome, tu devras justifier ta modification. Faire une bonne backdoor qui ressemble à une faille n'est pas facile.

    Justifier ? Mais vraiment… Tu crois que si je veux inserer une faille je vais envoyer un patch de 3 lignes ?
    Evidemment que non, je vais inserer une nouvelle fonctionnalite, un changement assez gros qui est utile, et au milieu il y aura cette faille qui passera inapercue.

    Faire une bonne backdoor qui ressemble à une faille et qui passe inaperçu quand on regarde uniquement le bout de code modifié est encore plus dur. Fair une bonne backdoor qui ressemble à une faille et qui est une modification justifiée du code est encore plus dur.

    Non c'est simplement que tu n'as aucune experience de comment le faire. Tu prends l'exemple des failles qui se retrouvent dans IE/Chrome/Firefox le plus souvent (use-after-free) et qui sont les pljus faciles a exploiter, il suffit dans ton bout de code d'oublier de faire un release sur un objet, ou mettre un acquire de trop (mauvais reference count). C'est tellement simple a faire que ces browsers en regorgent. Et le browser et la porte d'entree ideale pour des telephones mobiles, tablettes, desktops, …

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.

    Tu te tires toi-même une balle dans le pied:

    Du tout, je parles de backdoor dans un cas (un truc avere malefique), et faille dans l'autre.

    Et c'est un problème TOTALEMENT différent du fait de prouver quoi que ce soit (alors que tu reconnais par ailleurs que prouver une backdoor intelligente est impossible, je ne vois pas pourquoi tu continues à t'acharner là-dessus)

    Non c'est exactement la meme chose : reverse engineering pour voir ce qu'un code obfusque et complexe fait.

    et le pointage du doigt n'aura servi à rien (car si l'Europe, par exemple, veut vérifier, elle devra investir 1 an de boulot là dessus).

    Tu te fiches de moi ?

    Si je fais l'analyse en y mettant un an, et que je publie le papier, l'Europe n'a qu'a lire le papier, suivre les etapes et verifier. Ca prend qqe semaines a tout casser dans un cas complexe.

    Bref, c'est bien ce que je dis: montrer l'erreur dans l'assembleur, si cette erreur a été un minimum obfusqué, ça ne convaincra jamais aucun juge

    Visiblement tu n'as aucune experience de reverse engineering pour oser dire un truc pareil. Devines quoi, le code assembleur c'est du code, comme le C. Tu peux suivre son parcours comme en lisant du code C.

    Tu as prétendu connaitre le seuil de confiance de la communauté dans un contexte où ils ne se sentent plus client-vendeur mais partenaires et où la concurrence est plus grande.

    Partenaires ? Mais tu ne vis pas dans le meme monde mon cher. Les gens qui sont "partenaire" dans le monde libre sont une infime minorite des gens utilisant ces softs(principalement les devs). L'enorme, enorme, majorite n'y voit que des outils pratiques.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.

    Certainement, on ne peut pas prevoir le futur, mais clairement, ces dernieres annees, personne n'a eu le sentiment qu'il ne pouvait pas le faire.

    Personne ne peut dire qu'il y a une 'peur de se faire poursuivre' qui empeche les gens de publier des failles/backdoors dans Windows, les dernieres annees prouvent exactement le contraire.

  • [^] # Re: le code avait été audité

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    Aux US tout n'a donc pas besoin d'être écrit. Les juges n'écrivent pas les lois, ils disent le droit, ça s’appelle la jurisprudence.

    Pas vraiment non, ils se basent toujours au final sur la loi, et aucune loi ne dit que le gouvernement doit pouvoir avoir acces aux donnees des gens, de plus, il faudrait que cela soit publique parce que FISA, qui est la seule court 'secrete' n'a pas la possibilite de le faire, ils sont la pour une et une seule raison.

    Les révélation de Snowden ont montrées que les éditeurs US ont répondus à toutes les demandes du gouvernement US.

    Les revelations de Snowden n'ont RIEN montre sur les editeurs, absolument RIEN. Seuls les fournisseurs de services etaient affectes.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    Tu es sérieux ? Tu penses réellement que le type qui va mettre une backdoor dans windows va le faire se connecter automatiquement à son serveur ?
    Pourquoi ferait-il ça ?

    Tout a fait, tu viens de demontrer par A+B pourquoi il n'y a aucune difference entre un projet libre et un proprio : dans les 2 cas tu ne sauras jamais si c'etait une faille normale ou autre chose.

    Avec Linux, tu n'es pas obligé de changer d'OS. C'est ça l'important: tu peux continuer à utiliser le même code, mais gérer par une autre équipe, si tu as perdu confiance dans l'équipe initiale.

    Prends Redhat, Ubuntu, Suse, etc… et fais des stats sur combien de code est different.
    La seule possibilite de fork viable est si bcp de gens passent sur le nouveau fork. A moins que le gars qui insere une backdoor fasse ca de maniere totalement stupide, et on parle de la NSA ici hein, il n'y aura rien d'assez scandaleux pour que cela arrive.

    Si une faille est découverte, ma confiance diminue (peu importe sa raison d'être).
    On a trouvé une faille dans OpenSSL, et maintenant, il y a LibreSSL, parce que cette faille a été suffisante pour faire suffisamment baisser la confiance de certains. Et la question du fait que cette faille est une backdoor ou pas n'a rien à voir.

    Il y a eu LibreSSL parce qu'OpenSSL est connu pour etre un code vraiment pourri.

    Si je t'inseres une faille dans le kernel Linux par an, une autre dans Firefox ou KDE/Gnome, personne n'y verra rien, ca ne rendra pas des stats scandaleuses niveau decouverte de failles si elles sont trouvees, personne ne bougera.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 1.

    Toi tu n'as visiblement meme pas lu les 1ers slides.

    Leur objectif etait d'analyser Skype pour voir ce qu'il est possible de faire en tant que network/sysadmin, et leur conclusion parle de ce point de vue la, pas du point de vue d'un reverse-engineer.

    Pour un sysadmin, pas de possibilite de distinguer avec des regles sur traffic ou IDS, pour un reverse engineer qui analyse le binaire, c'est comprehensible par contre, la preuve, ils l'ont compris.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    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

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 6.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 5.

    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.

  • [^] # Re: le code avait été audité

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.

    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…

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 5.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

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

  • [^] # Re: le code avait été audité

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    Quel rapport ?

  • [^] # Re: le code avait été audité

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à -1.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    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…

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 2.

    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 !

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à -3.

    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.

  • [^] # Re: sourceforge non compromis ?

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 5.

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

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à -1.

    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.

  • [^] # Re: 1994

    Posté par  . En réponse au journal TrueCrypt, la fin ?. Évalué à 0.

    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.