Discussion :

[AlambicTalon]

Je me demandes si, pour un code source lu et relu et corrigé, le compilateur lui même, ne peut pas être vérolé et créer des portes dérobées ...

Disons que je trouve l'avenue de pirater le compilateur beaucoup moins probable et beaucoup plus laborieuse pour des résultats aléatoires.

Le compilateur gcc est encore plus surveillé que le noyau Linux par encore plus de développeurs. Et très souvent les développeurs du noyaux compileront leur propre compilateur à partir du source pour tester les derniers compilateurs et les derniers noyaux.

Il est beaucoup plus simple de s'entendre avec les distributeurs pour remplacer les noyaux ou autres utilitaires, parce que ça ne nécessite pas forcément de pirater le noyau pour obtenir des accès dérobés. Ensuite, espionner ne requiert pas non plus toujours d'avoir un accès direct à la machine, donc la porte dérobée n'est qu'une méthode parmi d'autres.

[Model_T101]

effectivement mais si ce n'est pas dans le noyau, il reste chaque logiciel, mise à jour, box internet, serveurs... donc pour espionner c'est largement ouvert.

[Traroth2]

Salut,

Je n'ai pas lu toutes les interventions, mais il faut se dire qu'il est "logique" (du moins, de leur point de vue) que les organismes américains dont le sigle est composé d'un I ou d'un A aient recours à l'espionnage : en dehors de l'espionnage, leur seule source d'information serait la délation et cette source est loin d'être suffisante.

Et quand on parle d'espionnage, on a le choix entre :

1. les jumelles et autres systèmes qui permettent de voir de loin (voir les micros directionnels) qui offrent une marge de manoeuvre assez limitée malgré tout
2. placer des micros et autres système d'écoute / de vision à l'intérieur des salles de conférence / conseil, mais bon, on n'est pas dans un film de James Bond
3. le recours aux complicités internes pour obtenir des informations ou placer des systèmes qui permettent de le faire.

Sans même verser dans la paranoïa, on peut très certainement imaginer que, le meilleur moyen parmi les trois que je viens de citer, celui qui apportera le plus de résultats exploitables en présentant le moins de risque pour "l'espion", c'est très clairement la complicité interne

Depuis le patriot act, les différents organismes américains ont "une base légale" qui leur permet de recourir à l'espionnage. Quelque part, ils auraient tord (de leur point de vue du moins) de ne pas profiter de cette possibilité!

D'une certaine manière, je serais pour ma part réellement étonné que de grands noms / de grandes firmes n'aient pas été abordées (ne serait-ce qu'au niveau d'un "pisseur de code quelconque") afin de trouver une complicité interne!

Et les raisons qui peuvent décider "quelqu'un" à devenir complice sont malgré tout nombreuses

Faut il s'en inquiéter très certainement! Ne serait-ce que parce que cela va à l'encontre même de certains articles de la constitution même des états unis, mais, surtout, parce que les systèmes d'exploitation sont distribués bien au delà des frontières US.

Faut-il verser dans la paranoïa pour la cause je dirais qu'un code ouvert du système d'exploitation permet de rester un peu plus serein.

Faut-il s'émouvoir de ce genre de demandes Très certainement, parce que cela fini par nous faire passer pour "tous potentiellement suspect (et donc coupable)" au lieu de partir de la présomption d'innocence.

Y a-t-il quoi que ce soit que l'on puisse faire Cette question reste réellement ouverte, mais, à part être vigilent, je ne vois pas grand chose d'autre

Notez bien que j'ai écrit "logique" et non "normal", "justifié" et encore moins "admissible (par le public)" car on ne peut en aucun cas estimer qu'il soit justifié ni même normal d'espionner les gens à grande échelle

NON, rien ne peut justifier l'espionnage systématique de tout le genre humain !

[koala01]

NON, rien ne peut justifier l'espionnage systématique de tout le genre humain !

Relis bien mon intervention (surtout la dernière phrase) et tu verras que c'est ce que je dis!

Ce que je dis, c'est qu'il n'y a rien de surprenant au fait qu'ils essayent, surtout qu'ils ont une base "légale" pour le faire depuis leur patriot act.

Ce que je dis, c'est qu'il est presque surprenant qu'ils n'aient pas encore trouvé (enfin que j'espère qu'ils n'aient pas encore trouvé) un tas de complicités dans les grandes firmes : la jalousie, le manque de considération, l'envie d'améliorer son quotidien sont autant de facteurs qui pourraient pousser "quelqu'un" à accepter de se faire complice de ces organismes. Je serais surpris s'il n'y ait vraiment "pisseur de code" chez microsoft, read hat, ou apple (et tous les autres) pour se laisser tenter par l'un ou l'autre de ces facteurs!

Cela ne veut absolument pas dire que je sois d'une quelconque manière d'accord avec la pratique, bien au contraire!

Simplement, à lire certaines interventions, on pourrait croire que les gens sont surpris que ces pratiques puissent exister, alors que s'il y a bien quelque chose de surprenant, c'est (du moins, je l'espère) le peu de réponses favorables qu'il reçoivent

[nico14Fs]

Bonjour,

rappelez-vous de l'affaire BSD : http://www.pcinpact.com/breve/60876-...o-de-raadt.htm.

Et logiquement tout le monde avait accès au code non ?

Évidemment, les contributeurs étant sans doute moins nombreux sur BSD, la chose était sans doute plus aisée ...

[sebman]

Et plus récement lorsque amazon choppait les recherches de l'utilisateur dans la version 12.10 de Ubuntu

Bravo a ceux qu'on publier ce scandal

[hurukan]

Pfff...

Il est clair que les algorithmes de cryptage utilisés dans le monde du libre doivent probablement être plus faciles à "casser" que ceux qui sont utilisés en qualité de prototypes dans les universités ou les laboratoires de la NSA et consors.

Maintenant, personnellement, j'utiliserais toujours Linux en me disant que comme le code source est disponible et donc ouvert, si je me décide à essayer d'y comprendre quelque chose en cryptographie, je pourrais aller voir ce qui est codé dans le code source et vérifier si il y a des "failles" potentielles, maintenant créer le buzz ou m'imaginer être espionné par des paranos franchement je pense qu'il y a quelque chose de mieux à faire dans sa journée.

Par contre concernant les codes "fermés" (Windaube et MacBidouille) là je serais plus ennuyé car je n'aurais pas envie de payer (trop cher) un OS pour le mettre à jour tous les jours (si pas toutes les heures) installer un wrapper Tor et tout le tralala... ça deviendrait ingérable.

Cependant je me demande quand même quelle technologie serait capable de sniffer tout le traffic d'un point A à un point B d'autant que les routes suivies par les paquets ne sont pas toujours les mêmes, pour aller en France des fois mes paquets passent par le Japon, il faudrait des logiciels capables de prévoir les routes empruntées par les paquets IP ou alors hijacker ceux-ci... cela impliquerait des collaborations à l'échelle mondiale (ISP, gestionnaires des infrastructures, ...) perso j'ai de grands doutes. C'est marrant d'investir sur les systèmes distribués pour finalement essayer de recentraliser le tout, ça n'a pas de sens.

Finalement j'en ai strictement rien à carrer: d'ailleurs je dis "Hello !" pour le gars/la bonne femme de la NSA/FBI/CIA qui lirait ce message. Histoire de rester poli.

[23JFK]

En y prenant le temps, petite touche par petite touche il doit être possible de véroler le noyau sans être repérer par ses pairs. L'autre point d'attaque se situe sans doute au niveau des compilateurs qui peuvent injecter du code non désiré par le programmeur lors de la compilation du noyau.

[imikado]

Bonjour,

rappelez-vous de l'affaire BSD : http://www.pcinpact.com/breve/60876-...o-de-raadt.htm.
.

Il faut suivre l'affaire en entier

Theo de Raadt made the email public on 14 December by forwarding it to the openbsd-tech mailing list and suggested an audit of the IPsec codebase.
(...)
In the weeks that followed, bugs were fixed but no evidence of backdoors were found

sources:http://en.wikipedia.org/wiki/OpenBSD...ec-backdoor-50
et
http://arstechnica.com/information-t...e-of-backdoor/

[koala01]

Il faut suivre l'affaire en entier

Theo de Raadt made the email public on 14 December by forwarding it to the openbsd-tech mailing list and suggested an audit of the IPsec codebase.
(...)
In the weeks that followed, bugs were fixed but no evidence of backdoors were found

sources:http://en.wikipedia.org/wiki/OpenBSD...ec-backdoor-50
et
http://arstechnica.com/information-t...e-of-backdoor/

Il faut se méfier à peu près autant de ce genre d'expression que des tests unitaires...

L'un dans l'autre, cela signifie "uniquement" que, dans l'état actuel des connaissances (sous entendu de ceux qui ont regardé le code), il n'ont rien trouvé qui puisse laisser penser qu'une backdoor puisse exister, tout comme le fait que les tests unitaires qui s'exécutent veulent, dans un certain sens, juste indiquer que, dans l'état actuel, tu n'as peut être simplement pas encore trouvé le scénario qui ne fonctionne pas.

Est-ce à dire que la preuve de la fiabilité est faite absolument pas! Cela veut juste dire qu'il n'y a pas (pour l'instant) de preuve évidente d'une faille ou d'un problème... C'est quand même fondamentalement différent

Bien sur, on peut estimer que ceux qui se seront attelés à ce problème savent de quoi ils parlent, mais ne donne malgré tout pas de garantie absolue.

Qu'il suffise pour s'en convaincre de voir le nombre de patches de sécurités qui paraissent sur des projets dont tous les tests unitaires sont pourtant passés avec succès

[imikado]

Je rappelle les faits:
1. Une personne publie un mail ou il avertit l'équipe de BSD qu'il a mis des portes dérobés à l'époque où il contribuait et demande un audit
2. l'audit est réalisé et indique ne pas trouver ses fameuses portes dérobés

Si portes dérobés il y a, il aurait pu (vu que le code est toujours disponible) en pointer au moins une pour "contrer" ce rapport d'audit et ainsi prouver sa bonne fois

Là on a l'impression qu'il a crié au loup, ou n'a jamais vérifié que son code de portes dérobés fonctionnait ou au moins n'avait pas été corrigé

[Pierre GIRARD]

Dans tous les cas, quand une faille de sécurité est découverte, que ce soit sur Linux, BSD, Windows ... ou n'importe quel OS ... ou n'importe quelle application sur n'importe quel OS : Les développeurs en charge du code incriminé font en sorte de corriger le problème.

Donc, si "porte dérobée" il y a eu ... SI ... alors, il est très possible que ça ai été corrigé depuis sans que personne n'en sache rien. Y-compris pour les développeurs de BSD qui ont très bien pu corriger ce qu'ils on pris pour de simple "BUG" sans même se rendre compte qu'un code malveillant avait été ajouté.

Ce que je sais, par contre, c'est que tous les jours (ou presque) j'ai des mises à jouir de sécurité à faire sur mon Linux (mais c'est automatique, et je le fais systématiquement).

C'est vrai aussi sur Windows, mais :

1. c'est beaucoup moins fréquent sur Windows
2. ça ne peut être pris en compte que par un reboot de la machine alors que pour Linux/BSD/Unix, c'est transparent.

Maintenant, d'accord avec le fait qu'un code ne peut être fiable à 100%. Même un développeur amateur comme moi (qui ne fait donc rien de très compliqué) s'en rend vite compte.

[skypers]

Le processe de développement rend l’insertion d’une backdoor compliqué et improbable. Mais bon, je repense à je ne sais plus quelle histoire (autour de bumblebee peut-être) avec le rm /usr /bin au lieu de /usr/bin…

[MacDev]

Oui, si on y prend pas garde.

[Rorry]

Impudence et naïveté de considérer Linux inviolable.
Il faut voir que la plus grosse partie du soft d'investigation peut
déjà être gravée en dur dans le microcode du processeur (Intel, AMD made in USA ...)

[wiztricks]

Impudence et naïveté de considérer Linux inviolable.
Il faut voir que la plus grosse partie du soft d'investigation peut
déjà être gravée en dur dans le microcode du processeur (Intel, AMD made in USA ...)

C'est un peu gros pour aller dans le microcode du processeur, par contre on a tout ce qu'il faut cote BIOS.
- W

[chrtophe]

Les gens qui seront le moins vulnérable à tout ceci seront ceux qui auront un vieux tél mobile incapable d'aller sur Internet, qui ne connecteront pas leur PC sur Internet (inenvisageable actuellement ), voire pas de téléphone. Ce sera aussi des suspects potentiels.

[n5Rzn1D9dC]

Les gens qui seront le moins vulnérable à tout ceci seront ceux qui auront un vieux tél mobile incapable d'aller sur Internet, qui ne connecteront pas leur PC sur Internet (inenvisageable actuellement ), voire pas de téléphone. Ce sera aussi des suspects potentiels.

Perso si j'avais vraiment des choses à cacher, je pense que c'est cette méthode que j'utiliserais.
Pas de ne pas avoir internet du tout bien sur, mais avoir un ordinateur non-connecté où tous les documents sensibles se trouverait dessus.
Bon c'est sur, pas simple pour travailler, mais au moins tu peux avoir l'esprit tranquille, tant que le média qui sert de transfert entre le pc connecté et le non-connecté n'est pas contaminé.

Il y a une époque où j'utilisais l'excellent Truecrypt, avec un disque virtuel, et un fichier vidéo comme mot de passe (ça c'est cool.. Pouvoir choisir n'importe quel binaire comme clef).
Ca me servait à stocker tous mes mots de passe.
Mais je ne m'en sert plus. Si la personne est déjà sur le pc lorsque tu tapes le mot de passe ou rentres la clef. Et si tu n'y es pas, bah il a juste à attendre que tu le fasses ^
En gros c'est encore plus sur d'avoir ses mots de passe sur papier..

Par contre niveau téléphone, mon internet est allumé uniquement quand je l'utilise. Car les OS téléphone sont relativement récents, et puis ça bouffe beaucoup de batterie inutilement en plus de ça (tout comme laisser la wifi ou le bluetooth allumé).

[berrandpb]

Encore une preuve que Linux gène.
Renouvelant ma confiance à Linux, je continue à conseiller son utilisation.

PB

[Mr_Exal]

Qu'en pensez-vous ?

On peut supposer qu'il en existe déjà un, voire plusieurs, dans Windows. Ce qui me pousse de plus en plus à vouloir changer pour Linux (malheureusement toujours pas de vrai support de jeux sous Linux )