Fort heureusement, une mise à jour du miroir CVS compromis depuis les serveurs principaux hébergeant l'arborescence BitKeeper des sources du noyau a permis de corriger le problème. Comment deux lignes de code malicieusement insérées pourraient fortement compromettre la crédibilité du noyau Linux.
Et aussi comment les méthodes de développement du noyau (architecture distribuée BitKeeper) permettent de se prémunir contre ce genre d'attaques.
Remarquons enfin que c'est la disponibilité du code source qui permet de déceler et corriger ce genre d'attaques. Qui sait combien de backdoors nébuleuses se cachent dans un code source propriétaire fermé ?
Aller plus loin
- L'article sur kerneltrap.org (30 clics)
- La dépêche OSNews (18 clics)
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Julien JEANY . Évalué à 10.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par jcs (site web personnel) . Évalué à 10.
Et eux aussi Ils offrent 250000$ à toutes personnes susceptibles de fournir des informations permettant de le retrouver ? :o)
je sais =>[]
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Olivier . Évalué à 7.
Ce qui m'étonne (enfin à moitié seulement), c'est de voir la dérive dans laquelle on s'installer ... à savoir de proposer de plus en plus souvent de l'argent pour retrouver quelque chose ou quelqu'un ... sans vouloir faire d'amalgame ça me rappelle des événements de mon cours d'histoire (oui je suis trop jeune pour les avoir vécus ...)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par a_jr . Évalué à 10.
L'argent pour l'argent, c'est mal. C'est de plus en plus en train de devenir un fleau en tuant les autres valeurs
Le bonjour chez vous,
Yves
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par isydor . Évalué à -3.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Yann Cochard (site web personnel) . Évalué à 10.
OK je --> [ ]
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par chooops . Évalué à 10.
[]<====
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Guillaume POIRIER . Évalué à 10.
Ainsi donc, ce genre de méprise ne pourrait se reproduire.
Je ne pense toutefois pas qu'une telle histoire puisse décrédibliser l'open source, (à part par les FUDers), car au contraire, elle montrera à quel point la communauté se réorganise vite face aux problèmes de ce genre...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par wistily . Évalué à -2.
Ainsi donc, ce genre de méprise ne pourrait se reproduire.
Bah, si ils ont réussi à committer sur le bitmachin truc en se faisant passer pour Untel, ils avaient sans doute les clés du gars.
La sécurité absolue n'existe pas.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Christophe Fergeau . Évalué à 10.
# méthodes qui le permettent
Posté par fragbait . Évalué à 10.
Il reste que sans des administrateurs vigilants et compétents sur leur système...
Pas de controle.
Le controle visuel étant plus productif en régime quotidien, que le controle actif : si les indicateurs se controlent d'un coup d'oeil on peut en controler plus en 1 minute, que si il faut passer une commande et lire une série de chiffres à chaque fois.
Mandrake est sur la bonne voie. Parallelement à ceux qui défendent une informatique de "pro", pour les "pro", par les "pro". Ou mème les puristes de l'integrisme qui prétendent se nourir de code et de communauté.
Défoulez vous. Je ne vote pas
[^] # Re: méthodes qui le permettent
Posté par Mr F . Évalué à 5.
Non y'a pas de raison, ton commentaire est interessant, un peu HS, mais interessant donc moi j'ai voté [+].
Concernant l'informatique "pro" et ton discours, c'est une opinion, qu'elle soit partagé ou non par le lecteur ne justifie pas, à mes yeux, un vote négatif ou positif.
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Ramso . Évalué à 10.
[^] # solutions libres
Posté par free2.org . Évalué à 7.
sinon pour le commun des mortels qui n'utilise pas les CVS pour avoir leur noyau il y a les signatures GPG des miroirs de kernel.org
http://kernel.org/signature.html(...)
[^] # Re: solutions libres
Posté par sneoo . Évalué à 1.
Pourquoi toujours sha2 (sha-256|384|512 en fait) ? SHA-1 est toujours considéré comme très sur par rapport à l'emploi qui en est fait.
[^] # plusieurs algos avec grosses clés
Posté par free2.org . Évalué à 4.
En dehors du onetimepad (et sous certaines conditions) aucun algo de crypto n'est démontré sûr mathématiquement.
Et régulièrement des failles sont publiées sur des algos qu'on croyait fiables...
Tout dépend aussi de l'importance des données à protéger: dans le cas du noyau Linux,
il mérite de larges précautions puisqu'il peut être utilisé par certains pour des données très importantes !
Quand on est "parano" (à tort ou raison) je pense qu'il vaut mieux utiliser plusieurs algos en même temps et avec des tailles de clé importantes ! (sans compter les bugs dans les implémentations de ces algos...)
[^] # Re: plusieurs algos avec grosses clés
Posté par Snark_Boojum . Évalué à 3.
La notion d'algorithme "sûr" telle que je l'ai entendue pratiquer en séminaires/groupes de travail, c'est:
* la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
* tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.
Cette notion de sécurité non garantie est pratique, mais a quelques inconvénients puisqu'une méthode sûre dans ce sens peut tomber:
* par chance: vous commencez votre attaque d'une clef à un endroit choisi au hasard, et vous tombez pile à côté de la clef réelle (très improbable);
* par progrès technologique: les machines deviennent des millions de fois plus puissantes soudainement (relativement improbable);
* par progrès scientifique: on trouve une nouvelle attaque (c'est souvent)
Pour info, les labos de crypto jouent à "la mienne est meilleure" (de méthode de cryptage); certains proposent une nouvelle méthode (ou une variante d'une méthode existante), et les autres rétorquent "Non, en faisant comme ci, comme ça, on la casse, ta méthode, essaie plutôt ça..."; bref, c'est assez amusant d'être assis dans les tribunes et d'admirer le spectacle.
Si vous voulez perdre votre confiance mal placée dans les méthodes de crypto actuelles, allez lire les conditions qu'on se donne sur les nombres premiers avant de les utiliser pour crypter, et dites-vous que chaque condition est apparue en réponse à une attaque possible...
Snark
PS1: si vous trouvez une liste qui se contente de demander "p, q: deux grands nombres premiers", vous n'avez pas trouvé une bonne page, les bonnes commencent par ça, puis enchainent sur:
* pas trop près l'un de l'autre
* pas congrus à bidule modulo machin
* p-1 ne doit pas se décomposer avec des nombres premiers trop petits
* ...
PS2: avant qu'on me pose la question, oui, j'utilise ssh et pas telnet, parce qu'entre rien du tout et une passoire, je préfère encore la passoire!
[^] # Re: plusieurs algos avec grosses clés
Posté par Julien Borrel . Évalué à 2.
Par contre, c'est inutilisable pour proteger le noyau. Ca ne peut servir grosso-modo qu'aux ambassades, genre tu envoies le CD contenant la cle dans la valise dilomatique, et tu peux ensuite t'en servir deux mois plus tard pour envoyer un email securise.
[^] # OTP pour tous
Posté par free2.org . Évalué à 3.
Non car je peux donner un CD ou un DVD contenant du random (=clé OTP) à des amis que je rencontre en personne sans être ambassadeur !
et en compressant bien les données à échanger, je peux ensuite échanger avec eux plusieurs messages textes (voir téléphoniques) par jour pendant des années en toute sécurité (et sans avoir besoin de les rencontrer en personne à nouveau)
[^] # Re: plusieurs algos avec grosses clés
Posté par Snark_Boojum . Évalué à 1.
Snark
PS: je dis "quasi" utilisable, parce que d'une part remplir un CD avec des données bien aléatoires, c'est pas tout à fait trivial, et d'autre part, son utilisation demande à ce qu'au préalable on ait réussi à faire transiter toutes ces données par un canal sûr...
[^] # Re: plusieurs algos avec grosses clés
Posté par mickabouille . Évalué à 0.
* tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.
Moi je n'utiliserais pas ça comme définition de sûr. C'est beaucooup trop subjectif, et peut évoluer.
Je dirais plutôt :
* L'attaque par force brute est la meilleure attaque possible (connue ou pas).
Après, le truc du million d'année ne veut pas dire grand chose, disons
* L'attaque par force brute est au moins de complexité exponentielle en une donnée de la méthode de cryptage.
Note que je n'ai vraiment que des connaissances très basiques en crypto (ce qui se voit certainement dans la naïveté de mes définitions), je suis plutôt matheux (ce qui se voit certainement dans...;)
[^] # Re: plusieurs algos avec grosses clés
Posté par Snark_Boojum . Évalué à 2.
Il suffit de jeter un coup d'oeil à:
http://csrc.nist.gov/encryption/aes/rijndael/Rijndael-ammended.pdf(...)
et comparer les parties 8 et 9... Respectivement "Ce contre quoi on s'est arrangé pour qu'il puisse résister" et "Les garanties". C'est pas une chambre à air avec une ou deux rustines, c'est un paquet de rustines.
En résumé: les définitions sont à la mesure de nos connaissances dans ce domaine: ridicules!
Snark
[^] # Re: plusieurs algos avec grosses clés
Posté par jcs (site web personnel) . Évalué à 2.
Attention, il faut bien distinguer algorithmes et protocoles. En crypto, l'un et l'autre sont importants.
Par exemple si tu prends RSA, considéré aujourd'hui comme sûr : l'algo est très simple, il peut être expliqué en quelques lignes (http://www.rsasecurity.com/rsalabs/faq/3-1-1.html(...)). En revanche pour chiffrer ou signer un e-mail par exemple, il faut un protocole qui va expliquer comment appliquer cet algo à un flux de caractères pour le transmettre comme un e-mail classique (cf CMS rfc 2630 et S/MIME rfc 2311).
Deux exemples ou l'utilisation d'un protocole foireux peut compromettre un algo sûr :
- on peut utiliser les messages d'erreurs concernant le padding pour réussir à trouver 1 à 1 les bits de clé. voir problèmes d'implémantation de la cryptographie : les attaques par effet de bord dans MISC n°4
- on peut utiliser les propriétés multiplicatives de RSA afin de forger des signatures valides. C'est très bien expliqué ici : http://www.eleves.ens.fr/home/coron/publications/thesis/node8.html(...)
[^] # Re: plusieurs algos avec grosses clés
Posté par sneoo . Évalué à 1.
[^] # Re: plusieurs algos avec grosses clés
Posté par free2.org . Évalué à 1.
Dans ce cas le fait d'avoir une clé plus grande (512 bits vs 128) reste un (exponentiel) avantage !
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Ramón Perez (site web personnel) . Évalué à 0.
De là à dire que c'est Linus lui-même qui a introduit la backdoor...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Brunus . Évalué à 3.
http://linuxfr.org/2002/10/23/10070.html(...)
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Christophe Merlet (site web personnel) . Évalué à -4.
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par pasBill pasGates . Évalué à 10.
Rien a voir, c'est un des developpeurs du kernel qui l'a trouve, pas un user curieux, le meme gars sur un soft proprio l'aurait trouve.
D'ailleurs, l'article le dit clairement :
Andreas Dilger pointed out that had the change gone undetected "it might have taken a good while to find".
Car ca n'a pas ete trouve durant une code review, ca a ete trouve pendant un export des sources ou ils se sont rendus compte que qqe chose de bizarre s'etait produit.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par boubou (site web personnel) . Évalué à 10.
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
Ce qui rend le truc difficile à trouver est que tout est dans (current->uid = 0) qu'on a tendance à lire (current->uid == 0), beaucoup plus anodin...
Moralité, je suis d'accord avec pBpG, l'aspect open source n'a pas grand chose à voir dans le problème présent.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Prae . Évalué à -1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Christophe Fergeau . Évalué à 4.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par boubou (site web personnel) . Évalué à 10.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Nicolas Melay . Évalué à -1.
C'est le genre de code sur lequel GCC te sort un gros warning, avec sirène et gyrophare.
Je ne sais pas si ça apparaît clairement dans une compil complète du noyau, mais en tout cas ça aurait été difficile à ignorer en travaillant sur du code voisin.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
Non. Pas avec les parenthèses autour.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à -3.
ok -> [], je connais la porte, merci :-D
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Nicolas Melay . Évalué à 1.
Ça fait bien longtemps que je n'ai pas écrit de C... :-/
(ni quoi que ce soit d'autre d'ailleurs)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par ookaze . Évalué à -2.
Ce n'est pas BitKeeper qui a permis de détecter quoi que ce soit, ce sont les scripts de mise à jour de BitKeeper vers CVS qui ont renvoyé l'alerte.
Ce sont des *scripts* (donc Open Source) qui n'ont pas été créés par les messieurs de chez BitKeeper !
Donc tout faux pour l'aspect non Open Source.
Voyant cette alerte, les messieurs qui gèrent tout ça ont été voir, et oh tiens, il a raison le script, c'est bizarre, demandons un avis ... et on connaît la suite.
Et je suis surpris que personne n'ait indiqué comment cette tentative a été découverte.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par boubou (site web personnel) . Évalué à 7.
"First of all, thanks Larry for detecting this. Your paranoia that made
you add extra checks on the export of data (also evident in the BK
checksums everywhere) probably saved Linux as a whole a lot of grief."
Mais bon, il faut savoir lire.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par fArAwAy . Évalué à 2.
Effectivement, c' est un développeur qui a trouvé cette tentative d' insertion.
Mais grâce à la disponibilité des sources, même un utilisateur curieux aurait pu le trouver, ce qui est n' est pas possible avec un soft proprio.
Quant à savoir si *le meme gars sur un soft proprio l'aurait trouve*, rien ne dit que ce n'est pas ce même gars qui l' aurait placé. Et dans ce cas, on en aurait rien su.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par pasBill pasGates . Évalué à 3.
Oui il peut, maintenant la realite montre que c'est tres rarement le cas.
Quant à savoir si *le meme gars sur un soft proprio l'aurait trouve*, rien ne dit que ce n'est pas ce même gars qui l' aurait placé. Et dans ce cas, on en aurait rien su.
Ben remarque, si ca avait reellement ete David Miller qui avait mis ce code, il n'y aurait pas eu cette bizarrerie a l'export des sources, et personne n'y aurait rien vu justement.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par - - . Évalué à 10.
merci de considérer que nous avons aucune certitude.
[^] # si on est parano seul le libre est acceptable !
Posté par free2.org . Évalué à 3.
la réalité c'est surtout que ce genre de "problème" est et demeure secret quand il arrive dans un soft proprio
alors que de + en + de gens (étudiants, professionels, paranos) apprennent comment est conçu un OS en regardant les sources de Linux
[^] # Re: si on est parano seul le libre est acceptable !
Posté par a_jr . Évalué à 10.
Et t'en fais quoi, de ce diff ? Tu ne vas pas quand meme prendre le temps de le lire *et de le comprendre*, si ?
Rien que recompiler systematiquement les rpms a partir des .src.rpm, ca prend du temps!!!
Et faire un diff, le relire, et le comprendre, parce que lire sans comprendre, ca ne sert a rien, moi, je n'ai que 24h dans ma journee, et encore, y'en a une bonne partie qui est consacree a dormir, a manger tranquilement, et a bosser (ou a etudier pour des etudiants).
Il est preferable, si on est parano, de suivre vraiment attentivement (donc de participer) l'un ou l'autre projet, et de faire confiance pour le reste.
Si vous voulez des gars vraiment parano, mais qui se donnent vraiment a fond et qui le font plutot bien, c'est les gars qui font l'audit du code de tous les softs d'OpenBSD. Mais ils sont a plusieurs, et ils ne le font pas en une soiree.
Le bonjour chez vous,
Yves
[^] # Re: si on est parano seul le libre est acceptable !
Posté par free2.org . Évalué à 3.
[^] # Re: si on est parano seul le libre est acceptable !
Posté par Yves Dessertine . Évalué à 0.
> temps de le lire *et de le comprendre*, si ?
Ben oui tu as raison, en plus si t'as pas une vue globale du bout de code sur lequel porte le diff tu comprendras rien !
[^] # outils pour présenter les diff utilisés par les mainteneurs de paquets
Posté par free2.org . Évalué à 3.
Je pense que de nombreux mainteneurs de paquets libres pour des distributions Linux utilisent ce genre d'outil, ne serait-ce que pour savoir pourquoi un nouveau paquet peut sembler marcher "moins bien" que l'ancien, ou pourquoi le patch spécifique à une distrib ne marche plus.
[^] # Re: si on est parano seul le libre est acceptable !
Posté par paparoot . Évalué à -1.
[^] # Re: si on est parano seul le libre est acceptable !
Posté par ckyl . Évalué à 2.
En gros si on est parano il faut tout construire (ecrire) de soit meme.
Rien ne te dis qu'a un niveau quelqu'un chose n'a pas ete backdooré.
Bref faire un diff c'est un peu ridicule. Rien n'est sur il faut simplement le savoir. De plus un (xxxx = e) a de grandes chances de passer inapercu pendant un moment. simplement pas ce que des tests d'uid == 0 y'en a toutes les 4 lignes et que l'oeil ne reste pas figé dessus. Le cerveau "voit" ce qu'il a envie de voir.
Après sous BSD ca aurait pas été possible celle la (suser() rulez :-))
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Obsidian . Évalué à 2.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par a_jr . Évalué à 4.
Quand on trouve un bug quelque part dans du code, il est vraiment appreciable de pouvoir le corriger soi-meme tout de suite (dans la mesure de ses propres competences) et de ne pas attendre que l'auteur diffuse un patch ou une nouvelle version avec la correction qu'on lui a envoyee.
Par ailleurs, quand on fait cela, il est toujours preferable de controler comment l'auteur a corrige la faille. a-t-il simplement applique notre patch ? A-t-il fait des corrections sur notre patch ? A-t-il supprime le bug autrement qu'en appliquant notre patch ? Ou n'a-t-il rien fait ?
Ce controle est d'ailleurs excellent pour l'apprentissage d'un langage car il permet de voir si l'auteur a fait pareil que nous, ou si notre patch etait imparfait.
Le bonjour chez vous,
Yves
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Olivier (site web personnel) . Évalué à 9.
En tout cas, le code inséré est pour le moins subtile : Il faut vraiment y regarder à deux fois pour voir le coup du "=" (affectation) au lieu du "==" (test de condition) dans le if...
Enfin, cet engouement pour le libre par des personnes de ce type ne peut signifier qu'une chose : Les logiciels libres prenent de plus en plus de poid sur les réseaux, et deviennent "intéressants" à pirater... A moins qu'ils en aient assez de faire du buffer overflow sur des trou de sécurité de IE, du RPC de Windows, etc..., et que finalement une backdoor dans le code source est plus facile à utiliser...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Caeies . Évalué à 10.
D'une part parce que des systèmes de sécurités interessants ont vu le jour (grsecurity, rsbac, exec-shield, SELinux, ...) qui contiennent au maximum les erreurs.
D'autre part parce que la rapidité de réaction d'un certain nombre de projets, rend la découverte des failles très aléatoires (sur une machine à jour :p).
Maintentant, Une backdoor est ce qui y a de mieux pour rentrer, c'est beaucoup plus discret qu'un exploit (qui peut ^etre très "bruyant"), et y a pas besoin de ce casser la t^ete pour trouver une faille.
En tout cas la porte dérobée introduite dans le noyau est très élégante :) et aurait pu passer inaperçue pendant un bout de temps, c'est clair.
mes 2 cents
Caeies, plongé dans le noyau et l'assembleur ...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Mathieu Pillard (site web personnel) . Évalué à 4.
irssi
bitchx
tcpdump
J'en oublie peut etre, mais je me souviens de ces 3 la. Accessoirement, xmms.org s'etait fait hacker a repetition. Enfin bref, je ne peux m'empecher moi aussi de faire mon parano et de trouver ca vraiment louche tout ca :)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Olivier . Évalué à 3.
Si 95% des machines tournaient sur un autre OS que ceux de Microsoft, je suis certain qu'il y aurait moins de bulletins de sécurité venant de chez eux ... car l'intérêt (pour certains) de trouver des failles s'en trouverait réduit.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Olivier (site web personnel) . Évalué à 0.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Christophe Merlet (site web personnel) . Évalué à 7.
Cette argument ne tient pas la route.
Apache détient 75% du marché des serveurs Web avec derrière du MySQL ou du PostgreSQL, c'est pourtant Microsoft IIS avec SQL Server qui est le serveur Web le plus compromis par les virus, les DDOS et autres!!
Je dirais même plus, il n'existe pas de virus pour Apache/PHP/MySQL/PostgreSQL.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par fabien . Évalué à 0.
Oui il y a plus de site web apache que IIS.
mais il y a plein de IIS qui tournent (a vide) a partir du moment ou il est (je crois) installé par defaut sous Windows 2000.
Donc le but d'un virus IIS n'est pas d'attaquer un serveur web, mais plutot un PC ou l'admin aurai oublié d'enlever IIS.
maintenant, pour les base de données, je ne sais pas trop, mais je ne crois pas que mySQL soit le number one ...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par a_jr . Évalué à 2.
Si on ne se limite pas aux LL, y'a Oracle, db2 et Sybase (j'en oublie surement) qui se portent bien.
Le bonjour chez vous,
Yves
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par sparky . Évalué à 1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par linuxidable . Évalué à -2.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par ookaze . Évalué à 4.
Ou alors j'ai pas dû tout comprendre ...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par chl (site web personnel) . Évalué à 5.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Yann Cochard (site web personnel) . Évalué à 10.
73,47% des statistiques sont fausses.
Yann
ok -> []
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Excellent :-))
Mais je voudrais savoir quel est l'intervalle de confiance à 99% de cette estimation qui pourrait, en première apprximation, suivre la loi de Fisher-Snedecor.
[^] # Fisher-Snedecor
Posté par Quzqo . Évalué à 2.
T'es gentil... tu ne sors pas de grossièretés de la sorte ici.
Merci ,o))
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à -1.
Y compris la statistique citée ci-dessus ;-)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Tonton Th (Mastodon) . Évalué à 3.
J'ai quand même vu, de mes yeux, un Apache claqué par cinik attaquer avec vigueur une tripotée de machines de la Nasa... Bon, ce n'est pas exactement un virus, mais plutôt un ver. Ceci dit, c'est pas en pinaillant sur les termes que l'on retrouvera la --->[]
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Gniarf . Évalué à 10.
je proteste bruyamment : n'importe quel programmeur C digne de ce nom sera déjà très mal à l'aise à la vue d'une affectation dans un test. oui, ça se fait tous les jours, mais parce qu'on sait ce qu'on fait, et le thème des affectations dans des if fait partie du top 10 des choses surveillées en C.
et n'importe quel programmeur du noyau ou orienté sécurité changera de couleur en voyant un current->uid = 0 se promener, où que ce soit. il SAIT ce que ça fait, et regardera dans le contexte ce que ça fait là.
Je ne parle même pas d'outils sérieux d'analyses de sources qui sont capables de surveiller ce qui arrive à une variable, même en l'aliasant, et cela sans rien compiler.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Christophe Fergeau . Évalué à 7.
et n'importe quel programmeur C repérera d'un seul coup d'oeil ce = au lieu de == après avoir relu 10000 lignes de code avant et avoir passé 6h devant son écran ?
Perso, je remarquerais probablement pas un truc comme ça en première lecture la moitié du temps.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Gniarf . Évalué à 7.
on sait à quoi elles ressemblent, on vient les chercher, avec une batte de baseball dans la main.
on peut faire des erreurs de frappe, on sait que le voisin de bureau peut en faire aussi, c'est rare qu'on ait une confiance absolue en d'autres personnes sur ce type de faiblesse humaine, donc oui, dans un environnement sérieux, ce type d'erreurs a une demi-vie plutot faible.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Nicolas GROSJEAN (site web personnel) . Évalué à -1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Yohann (site web personnel) . Évalué à 1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par fabien . Évalué à 5.
Bon je ne suis pas developpeur noyeau, mais je me dit que ca serait a la rigueur le contraire, mais en aucun cas ne renvoyer une erreur que si l'on est root...
Donc je pense que ce genre de lignes auraient intrigués un quelconque dev (des qu'il aura mis les yeux dessus)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par daggett . Évalué à 10.
Remarque, ce serait peut-être un patch anti-neuneu interessant, pour diminuer le nombre de gens qui bossent en root et pas en utilisateur normal...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Sébastien Koechlin . Évalué à 7.
+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+ retval = -EINVAL;
retval = -ECHILD;
si on passe par retval = -EINVAL, de toute façon la ligne suivante fait un retval = -ECHILD, c'est surtout cela qui est louche.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par fabien . Évalué à 3.
je n'avais pas fais l'effort d'aller chercher le source en entier...
et RAISON DE PLUS, un test qui modifie retval qui sera de toute maniere modifié la ligne suivante, c'est tres louche ! (voir inutile, sauf appel de fonction dans le if.. ou modification de variable)
donc bref :
en premier on vois : un test qui sert à rien (retval modifié tout de suite deriere)
ensuite, même en confondant = avec == on se dit tient on test si root pour envoyer une erreur ?.. rigolo ca..
ensuite (on ajuste ses lunettes) on voit le = et là on est sur que c'est pas honete comme ligne :)
donc je pense que ca serait pas resté longtemps...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par benja . Évalué à 2.
Serait-ce aussi évident à repérer s'il avait ajouté un else à la fin ?
Je crois que c'est un peu "juste" de compter uniquement sur les relecteurs de code pour garantir la sécurité d'un soft libre. Cleirement ce serait bien que le monde du dévelopement libre se dirige vers une structure garantissant une meilleure authenticité du code.
[^] # faire mieux, oui mais quoi ?
Posté par free2.org . Évalué à 4.
tu penses à quoi ? parceque là le compte (ie l'authenticité) d'un développeur semble avoir été piraté. Mais on s'est apperçu rapidement que y'avait une backdoor et elle a été enlevée.
.
Si le compte d'un développeur de MS est piraté, ils peuvent faire quoi de + eux ?
(à part nous cacher qu'ils ont aussi ce genre de problèmes)
[^] # Re: faire mieux, oui mais quoi ?
Posté par pasBill pasGates . Évalué à 0.
Alors a moins que le gars n'arrive a convaincre qq'un de l'interieur d'ouvrire un bug et le faire approuver par le meeting, il ira pas loin.
Je rentrerai pas sur les details qui concernent les criteres pour les machines et comptes autorisees a se connecter au depot car c'est probablement considere confidentiel, mais niveau securite c'est un autre monde que qui se fait dans le monde Linux ou chacun est libre de faire ce qu'il veut niveau securite.
[^] # bugs MS
Posté par free2.org . Évalué à 2.
[^] # Re: bugs MS
Posté par pasBill pasGates . Évalué à 2.
Le gars qui met du code et qui ne fait pas la requete sur le site web voit son code flagge le soir meme.
Resultat, des que le code est mis, 2 autres personnes au minimum sont averties, et elles sont au courant du status d'un bug, si ils voient une requete alors que le code n'est pas pret, ils vont reagir, le dev qui voit que son bug a ete marque comme corrige alors qu'il n'a rien fait va reagir, le reviewer qui n'a pas revu le code va reagir, etc...
Le fait que tout code entre doit avoir un bug associe fait que les gens savent ce qui est sense entrer dans l'arbre a l'avance.
[^] # Re: faire mieux, oui mais quoi ?
Posté par Erwan . Évalué à 1.
Tu me rappelles ton boss. Tiens, c'est pas Linux mais Mozilla: Nitot explique bien mieux que moi que dans les gros projets open source, il y a de l'organisation.
http://standblog.com/blog/2003/10/29/93113130-SteveBallmerEtLaQuali(...)
[^] # Re: faire mieux, oui mais quoi ?
Posté par pasBill pasGates . Évalué à -2.
1) C'est con, mais j'ecris pas du code car j'ai peur d'etre vire
2) C'est con, quasiment tous nos produits ratent la date de sortie prevue
8) Vu que la beta de chaque Windows passe chez plus de 500'000 personnes, je doutes enormement qu'il y ait plus de testeurs Linux que Windows, sans compter que chez MS, il y a un team dedie qui est probablement plus gros que les testeurs "intensifs" Linux.
Sinon, tu peux me detailler comment on fait pour s'assurer que la machine du developpeur qui se connecte au CVS est ok niveau securite ? Car c'est un point d'entree crucial ca.
Ah oui, il y a rien, on s'en remet au bon vouloir du developeur, c'est de ca dont je parlais.
[^] # Re: faire mieux, oui mais quoi ?
Posté par Erwan . Évalué à 2.
T'as juste en diagonale, et tu ne cites pas l'essentiel. Je te sors donc le passage a lire, c'est-a-dire la description du processus pour integrer une ligne dans un des principaux projets open source:
# Le développeur demande à un collègue de relire son code, et s'engage à faire des modifications qui lui sont envoyées en retour. C'est la notion de review.
# Il demande ensuite la super-review à un super-reviewer, un expert qui a une vision globale du projet, qui peut lui demander à nouveau des modifications pour une meilleure cohérence de l'ensemble du projet. (D'après ce que je sais, la notion de super-review est inexistante chez Microsoft)
# Ensuite, le code est intégré dans l'arbre CVS, qui journalise toutes les modifications faites au code. On sait à chaque instant qui a écrit ou modifié telle ou telle ligne de code, et à quelle date.
# Un ensemble de machines (les Tinderbox) compilent en permanence le code contenu dans l'arbre sur différentes plateformes. En cas d'incident à la compilation, le développeur (qui doit attendre la confirmation que tout s'est bien passé) retire son code de l'arbre.
# De plus, un systeme dit de CVS Blame permet de savoir qui est l'auteur de quelle ligne, et pourquoi elle a été rajoutée et modifiée (on connait le numero de bug correspondant, ainsi que les identifiants des reviewers et super-reviewers). Par exemple, voir l'historique du fichier editor.js de Mozilla. Autrement dit, chaque modification dans chaque ligne de code peut être littéralement tracée par qui veut...
Voila, ensuite si tu as le moindre doute sur un fichier (par exemple editor.js) tu vas voir la:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/ui/compo(...)
Et si j'utilisait un produit MS, je pourrais regarder moi-meme pourquoi chaque ligne a ete inseree, avec un lien vers le bug correspondant ? Non, je sais. Ce n'est pas grave, je n'en n'utilise pas ; mais ne vas pas dire que dans les projets Open Source les developpeurs se contentent de bidouiller chez eux et font un commit direct.
[^] # Re: faire mieux, oui mais quoi ?
Posté par pasBill pasGates . Évalué à -1.
Rien la dedans n'a permis de decouvrire la backdoor dont on parle, c'est bitkeeper qui l'a fait.
Et si j'utilisait un produit MS, je pourrais regarder moi-meme pourquoi chaque ligne a ete inseree, avec un lien vers le bug correspondant ? Non, je sais. Ce n'est pas grave, je n'en n'utilise pas ; mais ne vas pas dire que dans les projets Open Source les developpeurs se contentent de bidouiller chez eux et font un commit direct.
Faut que t'apprennes a lire.
La seule chose que j'ai dite, c'est qu'il n'y a aucune regle de securite quand a la securite des machines de dev des developpeurs, qui sont un point d'entree pour le CVS, je n'ai jamais parle des pratiques de developpement des devs de LL.
[^] # Re: faire mieux, oui mais quoi ?
Posté par chl (site web personnel) . Évalué à 1.
Que se passe t il si quelqu'un rajoute un bug "virtuel" dans la base de bugs, puis s'il inclut du code en l'associant a ce bug "virtuel" ?
Posée autrement :
En quoi le meeting journalier, empecherai quelqu'un d'inclure un bug "virtuel", lui permettant par la suite d'inclure du code ?
c'est un autre monde que qui se fait dans le monde Linux ou chacun est libre de faire ce qu'il veut niveau securite.
Linus n'inclue pas n'importe quel patch les yeux fermes, il le relit avant de le commiter.
[^] # Re: faire mieux, oui mais quoi ?
Posté par pasBill pasGates . Évalué à 1.
Sinon, quand je parlais niveau securite, je parlais des machines des developpeurs qui accedent au depot et la securite de ces machines la.
[^] # Re: faire mieux, oui mais quoi ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 0.
[^] # Re: faire mieux, oui mais quoi ?
Posté par pasBill pasGates . Évalué à -2.
[^] # Re: faire mieux, oui mais quoi ?
Posté par Chaddaï Fouché . Évalué à 2.
Je suis sûr que c'est possible pour la majorité des projets open sources de grande ampleur.
--
Jedaï
[^] # Re: faire mieux, oui mais quoi ?
Posté par Eddy . Évalué à 2.
Faudrait qu'on te présente kb< !
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par remi . Évalué à 2.
Si le type est assez malin pour introduire ce bout de code, et on peut supposer qu'il l'est (il faut connaitre un tout petit peu le fonctionnement du noyau pour avoir l'idée de pondre ce "patch", et en plus le coup des parenthèses placées autour de l'affectation démontre bien la volonté d'insérer ce code précis), alors donc, pourquoi se donner tant de mal puisque de tte facon ce code n'aura aucun effet ? (a cause du retval = -ECHILD).
Je ne crois pas une seule seconde qu'un mec capable de pondre ca soit ensuite assez mauvais pour ne pas volontairement faire en sorte que ce code n'ait jamais aucun effet.
Donc, pour moi, il n'a pas voulu "rééllement" plomber le noyau, mais alors pourquoi ? tirer la sonnette d'alarme en montrant qu'il était facile (ou au moins faisable) d'insérer une backdoor dans un projet comme Linux ?
Honnêtement, je n'ai pas de réponse assurée. et vous ?
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par benja . Évalué à 1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Tonton Th (Mastodon) . Évalué à 2.
Ah, tu en es sur ?
current->uid = 0
gOt r00t !
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par a_jr . Évalué à 6.
A condition de lire cette ligne attentivement.
je peux te dire, pour avoir deja fait cette erreur en tant que faute de frappe (mettre = a la place de ==) que c'est pas souvent une erreur facile a trouver.
Une fois que quelqu'un a repere le = a la place du == a cet endroit, comme tu dis, il va bondir et chercher a comprendre. Tout a fait d'accord. Encore faut-il l'avoir repere.
Le bonjour chez vous,
Yves
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Gniarf . Évalué à 4.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
Seulement, là, il a bien mis les bonnes parenthèses pour éviter le warning, donc, les "bons outils" dont tu parle, ils se disent "Ouh la la, ça craint !!! ... Ah, non, il me fait signe qu'il a fait exprès."
Si tu fais un outil qui donne un warning dès qu'il trouve une affectation dans un if, tu vas avoir des centaines de warnings sur un gros programme en C, vu que c'est une pratique assez courrante, genre
if ((x = next_value())) {
...
}
Tiens, j'en ai une dans un exemple de la libc :
http://www.gnu.org/software/libc/manual/html_node/Example-of-Getopt(...)
Ce genre d'outils est très efficace pour trouver des fautes d'inattention (déjà, compilez avec -Wall -Werror, ça limite vachement la casse), mais contre une backdoor volontaire, tu ne peux pas faire grand chose.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Delannoy Maxence (site web personnel) . Évalué à 5.
Vive le pascal libre !
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Pierre Jarillon (site web personnel) . Évalué à 0.
0 -> X -> Y
ce qui se comprend sans aucun effort. Le signe = était uniquement réservé au test.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Alexandre Beraud . Évalué à 1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par MrTout (site web personnel) . Évalué à 1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Alexandre Beraud . Évalué à 1.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Pascal Lambert . Évalué à 1.
C'est vrai, si Linux était fait en PASCAL, on avancerai + vite, PASCAL est plus propre. On ne peut pas inclure d'affectation
dans un autre élément, et en plus,on peut faire des proc/func's privées dans d'autres proc/func's.
C'est la différence entre une radio avec des fils partout ( le C ) et une radio dans lequel il y a des cartes électroniques, c'est un systeme qui peut rendre la technologie objet moins utile !
( l'objet est une mode, qui sera remplace un jour ) Une preuve, on trouve de plus en plus de revues (voir l'Informaticien) qui parlent et disent énormément de bien du fonctionnel : même Micro$oft s'y met (le F# est un camel pour .Net) .... Le futur, c'est le fonctionnel (vais essayer de m'y mettre...)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Snark_Boojum . Évalué à 1.
Snark
PS: je plaisante! ;-)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Olivier (site web personnel) . Évalué à 4.
Je parlais du fait que ce n'est pas visuellement très repérable : Un caractère "=" en moins au lieu de 2, cela passera inapercu à une lecture peu attentive du code.
Mais évidement, au niveau de la sémantique du C, ce type de code est une horreur. Lorsque je code du C, je ne fais bien sur pas ce genre de chose...
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par ookaze . Évalué à 8.
Et donc, ce genre d'erreur, je n'ai plus à m'en soucier.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par kesako . Évalué à 6.
a = ...
if (22 == a ) {
}
au lieu de if (a == 22)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par mathieu mathieu (site web personnel) . Évalué à 4.
De plus ca n'est pas très lisible (dans la logique on teste la variable par rapport à autre valeur....)
Ce que l'on fait dans mon taf, c'est qu'on fait passé une moulinette qui verifie si les affectations sont imbriqués dans les parenthéses d'un if (ou d'un while etc.). C'est plus bourrin, mais efficace!
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Pascal Kuczynski (site web personnel) . Évalué à 6.
c'etait quand meme autre chose! :-)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par kesako . Évalué à 5.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Snark_Boojum . Évalué à 8.
Snark
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Ramso . Évalué à 7.
# Et si il y avait un backdoor non trouvé ?
Posté par ramzez . Évalué à 3.
quand on voit les millions de code que comporte un systeme linux à base de kde, xmms, diverses services tels que ssh ou proftpd ... on ne peut être sur.
Donc ma question est : parmi tous les récents systèmes de sécurité qui ont vu le jour dans linux, y-en a t-il un qui permettrait de détecter des comportements étranges provenant d'un élément du système ? Même un truc bien fastidieux qui ne serait fait que par le développeur lui même mais qui permettrait d'être sur qu'il n'y a aucun problème ? Je ne vois pas de solution miracle mais ce genre de problème me parait suffisamment important pour qu'une solution fiable soit trouvé.
d'ailleurs j'hésite bien souvent à prendre des paquets non officiels de ma distrib s'ils ne viennent pas du mainteneur lui même à cause de ça
bon, je sais, je suis parano, mais comme on dit : on est jamais trop prudent
[^] # Re: Et si il y avait un backdoor non trouvé ?
Posté par kapouik . Évalué à 6.
Sûr, non. Mais ce qui est certain, c'est la disponibilité du code source pour les développeurs qui travaillent sur un logiciel rend difficile l'introduction de code douteux (mais théoriquement pas impossible). À noter que si de telles backdoors volontaires existaient déjà, elles seraient exploitées - c'est le but après tout - et il y a de forte chance que cela aurait été su.
> Donc ma question est : parmi tous les récents systèmes de sécurité qui ont vu le jour dans linux, y-en a t-il un qui permettrait de détecter des comportements étranges provenant d'un élément du système ? Même un truc bien fastidieux qui ne serait fait que par le développeur lui même mais qui permettrait d'être sur qu'il n'y a aucun problème ?
Comment veux-tu qu'un système puisse détecter un comportement étrange ? Cela supposerait l'analyse et la compréhension de la logique de chaque séquence de code, ce qui est d'une part énorme et d'autre part inexistant à ce jour. Pour couronner le tout, dans la série du chien qui se mord la queue, qu'est-ce qui assurerait que ce système est de digne de confiance ? :)
Par ailleurs, est-il besoin de tomber dans la paranoïa ? Non, il faut faire confiance par la communauté du Logiciel Llibre qui a prouvé sa compétence depuis des années déjà, et qui a déjouée les multiples sabotages dans ce style. Sinon, autant utiliser un système propriétaire, au moins on suppose qu'il y a qu'il y a des backdoors par avance et on dort tranquille le soir :)
> d'ailleurs j'hésite bien souvent à prendre des paquets non officiels de ma distrib s'ils ne viennent pas du mainteneur lui même à cause de ça
La plupart des projets dispose d'une clé GPG pour contrôler la signature des sources et s'assurer qu'elles proviennent bien des auteurs originaux : personnellement, je vérifie tout le temps cette signature, car c'est un gage de sécurité et une habitude à avoir quand on est soucieux de la sécurité (surtout en milieu professionnel).
De même, les mises à jour d'une distribution peuvent être contrôlées de manière sûre grâce à la clé GPG des mainteneurs, et cela, quelque soit le mirroir sur lequel se trouve la mise à jour. Par exemple, avant d'appliquer un paquet de mise à jour à mon système Slackware, je le vérifie vérifie avec GPG pour m'assurer que le paquet de mise à jour est sûre car il provient bien des mainteneurs. Cela suppose évidemment que les mainteneurs font de même lorsqu'ils téléchargent les sources d'un logiciel pour en faire un paquet, ce qui est le cas pour la plupart des distributions Linux.
[^] # Re: Et si il y avait un backdoor non trouvé ?
Posté par gebura . Évalué à 1.
Je delire c est certain mais ...
[^] # Re: Et si il y avait un backdoor non trouvé ?
Posté par benja . Évalué à 1.
[^] # Re: Et si il y avait un backdoor non trouvé ?
Posté par grafit . Évalué à 8.
Pour modérer un peu le propos (sans pour autant dire que c'est impossible), Linux et autres LL ne se sont pas fait en un jour, et les changements sont en général *petits* et *suivis*. Il arrive que des patchs soient refusés avec pour seul motif leur taille. (trop gros, passera pas ;-)
Quel mainteneur accepterais un patch de 4000 lignes de la part de xxxds@yahoo.com ?
Quel mainteneur intègre un patch sans le relire ?
Par récurence, un premier dépot de zéro ligne, puis des rajouts auditables et audités, donc sûrs, et le tour est joué. Une duplication des dépos: toute différence est une erreur. Le reste n'est que bug.
Bref, ce n'est pas vraiement comme si on se retrouvait du jour au lendemain avec 20 million de lignes à inspecter.
# On se calme! On n'est pas (encore) Slashdot
Posté par oliv . Évalué à 10.
Tout cela est bien joli, mais comme disait Fontenelle, "Assurons nous bien du fait avant que de nous inquiéter de la cause".
1- un backdoor a été inséré dans le code de Linux: FAUX
Il a été inséré sur un miroir. Si j'insère un backdoor dans le code du noyau Linux à la maison, est-ce que je vais crier "Un backdoor a été inséré (par moi) dans le noyau linux!". Ce serait vrai mais complètement con.
2- il aurait pû rester là pendant des mois/années etc. FAUX
Il n'est que dans un miroir, donc il disparaît à la prochaine synchronisation sur le site d'origine.
3- open source = pas sûr, c'est prouvé (je schématise)
Le noyau linux n'était pas géré par CVS. Le noyau linux utilise très lourdement le peer review. Et c'est ce qu'a compris l'affreux, en essayant de s'attaquer au serveur CVS.
4- ce backdoor pouvait ne pas être repéré, à cause du = au lieu de ==
Il suffit de lire la LKML pour se rendre compte que chaque ligne est vraiment lue par Linus et ses lieutenants. Il pinaille très souvent sur des détails (détails pour un profane comme votre serviteur ;) ), alors une "erreur" de ce type, ne pouvait pas passer.
D'après le thread, les gens de BitKeeper (= Larry McVoy) ne se sont pas rendu compte de l'existence du back door dans le code, mais ils ont remarqué que l'accès CVS était illégal et c'est ça qu'ils ont corrigé. Quand McVoy a écrit sur la LKML, quelqu'un lui a demandé de poster le code en question, et les 3 réponses qu'il a eu dans les 10-20 minutes (Zwane Mwaikambo, Andries Brouwer et Chad Kitching) sont claires: "c'est un back door", d'où sa réponse:
"It sure does. Note "current->uid = 0", not "current->uid == 0".
Good eyes, I missed that."
Bref, le code n'a pas passé le peer-reviewing
Cet évênement n'en est pas un. Le code de Linux, qui se trouve ailleurs, n'a jamais été contaminé.
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par David Douard . Évalué à -1.
Yes !
PS : est-ce plussoir ou plussoyer le bon verbe ?
Il faudrait une Académie LinuxFR !
David
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par PloufPlouf (site web personnel) . Évalué à 1.
mais si tu mets un e à 'je plussoie' (en l'occurence tu as ecris 'poussoie' mais c'est pareil), c''est que c'est un verbe du premier groupe donc plussoyer, tu as repondu toi-même à ta question... t'es pas si nul ;-)
sinon il aurait fallu ecrire 'je plussois' je pense
voir les verbes boire et aboyer par exemple
je peux être academicien ?
parce que pour developper le noyeau, je vaux rien...
d'ailleurs je vous fais remarquer au passage que l'on n'invente plus que des verbes du premier groupe
http://www.leconjugueur.com/frindex.php(...)
--
plouf
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par David Douard . Évalué à 1.
Enfin, pour le fait que l'on n'invente plus que des verbes du 1er groupe, ça ne m'étonne pas... Comme disait l'autre, on sacrifie toujours quelque chose à la facilité.
QUIZZ
Cette citation est extraite d'un film français, sauras-tu le reconnaitre ?
Tout fout le camps, mon bon monsieur.
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
Je n'aime pas le verbe du troisième groupe car c'est dedans qu'on a mis tius les verbes malades, bancals, pestiférés et mal fichus.
L'antonyme de plusser serait moinsser. Mais faut-il deux S ? Un seul serait suffisant, mais il me semble qu'il est normal de doubler de S final de moins pour en faire un verbe. Un grammairien SVP pour nous éclairer !
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par Eddy . Évalué à 5.
Ce sont tous les deux des verbes irréguliers du 3e groupe.
Ras le cul des verbes du premier groupe.
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par durandal . Évalué à 2.
Donc logiquement on devrait dire moinsser et plusser :)
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par charlieecho . Évalué à 7.
Tout dépend de qui s'y cache...
La tentative a raté, mais il serait bien intéressant de savoir qui a essayé.
Le "pirate" a usurpé une identité ; il a su pirater CVS ; et en plus, il connaît le kernel vraiment bien.
A mon avis, les "pirates" bas de gamme ne connaissent pas bien le code ; ils connaissent les outils pour s'introduire dans un système. Et le codeurs "haut de gamme" ne sont pas des pirates.
Bref, ce pirate est sacrément "doué".
Reste à savoir qui a fait le coup...
Côté événement, je trouve plutôt que c'est un argument en faveur de l'Open Source...
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par Pierre Jarillon (site web personnel) . Évalué à 0.
Un première hypothèse serait un vengeance d'un développeur écarté du kernel. Je n'y crois pas car la réaction normale serait de faire un fork et de démontrer qu'il existe de meilleures solutions.
Si ça avait marché, à qui est-ce que ça aurait rapporté ? Aux ennemis du logiciel libre, bien entendu. C'est ce qui me parait le plus plausible.
Dis pBpG, tu n'aurais pas entendu parler de ça autour de toi ?
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par pasBill pasGates . Évalué à 0.
T'as rien de moins con a dire ? Parce que dans le genre FUD, t'es un champion
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 2.
cf http://france-zdnet.com.com/1601-2-5095074.html(...)
Ok, on FUDe, mais Steve, scuse-moi, il en tiens une sacré couche.
developpers developpers developpers developpers
où ça ? ah oui -------------->[]
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par dcp . Évalué à 3.
Il est quand même pas au niveau de MS, qui est l'inventeur du genre.
A priori, le FUD c'est la seule innovation réelle de MS (ie: ils ont pas racheté une boite)
sans rancune, et oui je suis dehors.... :-)
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Merci du compliment, mais je n'arrive pas à la cheville de ton patron.
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par boubou (site web personnel) . Évalué à 4.
Non tu déformes. Ce que certains ont dit, c'est que le fait que le noyau soit open source n'a probablement rien à voir avec la découverte rapide de la tentative.
Bref, le code n'a pas passé le peer-reviewing
Quelle grossière simplification ! Tu connais la différence entre le jeu des erreurs et le jeu des 7 erreurs ? Tu sais pourquoi le deuxième est plus facile ? Encore heureux que des rois du noyau linux aient compris rapidement le but de cette insertion de lignes. Je ne suis pas sûr qu'au milieu d'un patch compliqué, quelqu'un détecte facilement une différence entre un = et un ==. Par sûr que cela puisse être facilement utilisé pour insérer une backdoor viable, ceci dit car un test sur l'uid est quand même quelque chose d'important et si ça arrive n'importe où, ça sera tout de suite louche. Par contre une petite modification d'un test permettant ensuite de déclencher un buffer overflow...
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par ookaze . Évalué à 8.
Et pourquoi crois-tu que Linus a toujours refusé les patchs compliqués ???
Linux n'accepte que les patchs simples, et ses "lieutenants" aussi., sinon : poubelle !
[^] # Re: On se calme! On n'est pas (encore) Slashdot
Posté par oliv . Évalué à 4.
----------------------
On Thu, 6 Nov 2003, bert hubert wrote:
>
> And, was there any route via which this malicious patch could've worked
> itself into a kernel release?
No. There are two ways to get into a kernel release: patches to me by
email (which depending on the person get more or less detailed scrutiny,
but core files would definitely get a read-through and need an
explanation), and through BK merges.
And the people who merge with BK wouldn't have used the CVS tree.
Linus
-----------------------
( http://marc.theaimsgroup.com/?l=linux-kernel&m=106813487330283&(...) )
Bref Linus qui n'est pas un j'menfoutiste au niveau de la sécurité conclut clairement que ce patch n'avait AUCUNE chance de se retrouver inclus dans le code de Linux.
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Alan_T . Évalué à 7.
Larry McVoy wrote:
> On Wed, Nov 05, 2003 at 04:48:09PM -0600, Chad Kitching wrote:
>>From: Zwane Mwaikambo
>>>+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>>>+ retval = -EINVAL;
>>
>>That looks odd
>>
>>
>>Setting current->uid to zero when options __WCLONE and __WALL are set?
>>The >>retval is dead code because of the next line, but it looks like an attempt
>>to backdoor the kernel, does it not?
>
>
> It sure does. Note "current->uid = 0", not "current->uid == 0".
> Good eyes, I missed that. This function is sys_wait4() so by passing in
> __WCLONE|__WALL you are root. How nice.
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par tcws . Évalué à 10.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Alan_T . Évalué à 3.
De toute façon, de plus en plus de gens ont intêret à ce que Linux fonctionne bien. Des personnes privées, mais aussi des entreprises comme IBM, Motorola, et même Intel. Alors, cette éventualité est tout de même assez marginale.
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par mickabouille . Évalué à 2.
On vient de voir que quelqu'un d'intelligent pouvait cacher des trucs dans du code apparemment anodin.
Y doivent bien avoir quelques gars intelligents à la NSA (collaborateurs du noyau, via selinux)
Bon allez, j'arrête ma parano et je vais prendre mes pillules
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par maxIharD . Évalué à 1.
De plus en plus de gens ont intérêts à placer des backdoor dans Linux et le libre car ces solutions sont de +en+ utilisées… (enfin!!!)
Les amateurs de virus et autres vers pour ce faire … à la vue des problèmes posés par leur 'création' mais également les Autres, intrus restant dans l'ombre, qui ont beaucoup plus d'intérêts à défendre… Gouvernements (style NSA, armée, police, …), Les majors qui peuvent claquer des M$ pour ca … sans oublier les mafias et sectes de tout poils…
Mais il n'y a pas que le soft! Qui peut certifier qu'il n'y a pas de backdoor directement dans le hardware (carte réseau, CPU, Bios, …)
Si les informations traitées ont de la valeur, ceux qui les voudront y mettrons le prix et les moyens (un gouvernement ou ceux qui ont bcp de $€ peuvent se permettre des actions 'sur le terrain'). Et dans ce cas, même la crypto 'parfaite' a un intérêt limité …
Force est de constaté que le nombre de 'grands frères' est en augmentation constante et que d'une manière générale la société de l'information est, pour eux, un formidable outil d'automatisation… donc de réduction des coûts…
Bref, d'une manière générale, la ?seule? solution est de rendre le coût d'une violation de votre intimité bien supérieur aux bénéfices … de vivre caché et d'utilisé des 'systèmes' hors standard, exotiques à souhait et indépendants les uns des autres…
Pour ma part, j'ai pas grand chose de valeur, donc ca n'a pas été trop difficile.;-)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par smorico . Évalué à 1.
J'ai bien peur que tout le monde soit suseptible de céder. Il faut donc faire avec.
"c'est quoi qui pourrait vous faire flancher ?" : si tu ne veux pas que ca t'arrive il faut certenement se poser aussi une question qui doit être du genre : "comment faire pour que personne n'est interet à nous faire flancher. ?"
[ maxIharD ]
Bref, d'une manière générale, la ?seule? solution est de rendre le coût d'une violation de votre intimité bien supérieur aux bénéfices de vivre caché et d'utilisé des 'systèmes' hors standard, exotiques à souhait et indépendants les uns des autres
?seule?
pas con mais il faut pas oublier qu'il on BEAUCOUP d'argent.
Utiliser des trucs pas connus et donc dur à avoir pourrait être la meilleur facon d'attirer l'attention.
sinon vivre cacher mois ca me fait flipper. Parler à visage découvert c'est secure. s'il venait à arriver quelque chose à un pseudo, que l'affaire soit etouffé. Personne d'entre nous ne pourra en savoir plus. Peut être même qu'aucun d'entre nous n'en sera au courrant. Je n'ai rien à cacher mais peut tous le monde à le droit d'être un peut parano et on n'est pas à l'abri d'un incompréention de la part du méchant oeul ;)
Aprés tout c'est peut être Miller ou Linus qui fait un test pour voir si ces potes codeurs sont bon :DD
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par smorico . Évalué à 1.
J'ai encore paumé mon poste ! je refai(?) :
>> [ maxIharD ]
> Bref, d'une manière générale, la ?seule? solution est de rendre le coût d'une violation de votre intimité bien supérieur aux bénéfices ?
Pas con mais oublis pas qu'ils ont BEAUCOUP d'argent. Et que les bénéfices, ça doit pas être sur TOI qu'il les fond(?) alors...
> de vivre caché et d'utilité des 'systèmes' hors standard, exotiques à souhait et indépendants les uns des autres?
C'est peut être aussi le meilleur moyen de te faire remarquer. Le matériel exotiques ça doit pas être simple à trouver et donc... ça risque de faire du bruit. Tu peut tjs te le construire ;)
Et encore si tu lis trop de doc trop bien tu attire peut être aussi l'attention. nan ?
> Mais il n'y a pas que le soft! Qui peut certifier qu'il n'y a pas de backdoor directement dans le hardware (carte réseau, CPU, Bios, ?)
Même si on utilisais du matos très open, et si on était bon au point de comprendre TOUS ce que fait ta machine. Qui te garantis qu'il n'y est pas une door dans ton radio réveil.
Déconne pas c'est possible. Vu que tout matériel émet des ondes éléctro qui peuvent être interprétés pour comprendre ce qu'il se passe à distance. hihi
> Bref, d'une manière générale, la ?seule? solution....
c'est peut être celle-ci :
> Pour ma part, j'ai pas grand chose de valeur, donc ça n'a pas été trop difficile. ;-)
La pire des solution est de vivre caché.
[ tcws ]
> .... Parceque il y en a des gens que le développement de linux gêne qui peuvent se le permettre, et que les développeurs ne sont pas forcément nantis ou incorruptibles, non ? et vous si on vous offre un million pour subtilement introduire des backdoors dans le noyau ? ou si quelqu'un exerce des pressions sur vous ? c'est quoi qui pourrait vous faire flancher ? quelles sont les chances qu'une telle chose ne soit pas détectée ? est-on sûr de pouvoir remonter au coeur du problème si jamais ça arrivait ?
Ce qui me fait le plus peur est le "c'est quoi qui pourrait vous faire flancher ?" et "[...] si jamais ça arrivait ?" sans un truc du style : "comment faire pour qu'il n'est pas interret à te faire flacher. ?"
Le meilleur moyen n'est pas de ne rien avoir à cacher. tu n'est pas à l'abri d'une incompréention de leur part. Le meilleur moyen n'est pas de te cacher derrière un pseudo car s'il t'arrivait quelque chose, je/(on?) ne POURRAI RIEN POUR TOI ;)
Le meilleur moyen est d'être honete et de "dire ce que tu fait. de faire ce que tu dit". (pas tout quand même).
Le meilleur moyen est la coopération. Et si tu est honete (je parle pas de la lois car elle est trop imparfaite pour fonder des bases - et c'est pas une raison pour ne pas la respecter !), tu n'a rien à craindre et eux non plus.
Après tout ce que tous le monde veux au fond. C'est de la paix et un peut de respect dans ce putain de monde. Linux est basé là dessus. Le fait qu'il soit libre est seulement un mailloin (fort) de sa sa philosophie.
Nous sommes plus fort car nous sommes honetes.
copérons.
"ce post est sous GPL" ;)
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par Simon Huet . Évalué à 2.
Euh ... couper la barde d'Alan Cox ?
Ok -----> [ ]
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par manuel . Évalué à 6.
la machine par laquelle le code malicieux a été introduit. Ils
vont inspecter le disque dur avec une (grosse) loupe pour
essayer de comprendre ce qui s'est passé.
manuel
[^] # Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par charlieecho . Évalué à 4.
1° voir si il n'y a pas de Trojan sur la machine
2° voir par où la personne est passée, pour comprendre le trou de sécurité
3° voir qui c'est ; mais si le gars est "bon", il ne laisse pas de trace repérable...
# Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Posté par vjm . Évalué à 4.
D'ailleurs c'est dans le thread de la lkml dont les mails ont été copié dans l'article de kerneltrap : ça aurait pu arriver à du propriétaire et être découvert tout pareil.
L'open source c'est bon pour la sécurité et la fiabilité si y'a des gens compétents derrière. Mais ces mêmes gens compétents peuvent aussi bien faire qqch de secure et fiable dans le propriétaire...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.